Sunday, August 3, 2014

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.

1 comment: