Good Security Practice for Programmers

This is the one of a series of posts on "Good Data Processing Security Practices."  The context for the series can be found here.  The following practices and controls are for enterprise development programmers, the individuals who produce the computer programs on which enterprise managers wish to rely.  Like other posts in this series, this post suggests useful separations of duties to ensure quality and fix accountability.

An individual programmer should not both specify and write a procedure.

Should not both write and test a procedure.

Should not both create and maintain a procedure.

Should not name procedures that he writes. (Program names are analogous

to account number which are normally assigned as part of the approval

by management or a designee separate from the originator).

Should not both write and execute a procedure (exception: data local to

himself as in testing or personal computing).

Should not both program and maintain the program library (exception:

they do all maintenance to that library).

Programmers should have personal copies of specifications. data definitions. source

code. test data. test results. load modules and object modules. All transfers

between the programmers personal libraries and project or production

libraries should be controlled by someone else.

The above represents the ideal. Because of limitations of scale, it may not be

realizable in all installations. However. under no circumstances should one

person specify, write, test. name. maintain and execute the same program.