Good Security Practices for Program Libraries

This is the second 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 program libraries, i.e., collections of programs related to one another for purposes of management and control.


Only one person should be allowed to make changes to a program (library).

The person who changes the program (library) should not write any of the changes (or he should write all of them).

All changes to a program (library) should be authorized by management.

All changes to a program (library) should be logged as to the event. the authority, and the content.

Content of the library should be known (in terms of named and structured sub-libraries. named modules. bits and bytes) to at least two people (e.g..developer and user. operations and user).

Content of the library should be reconciled to the expected content on an appropriate and adequate frequency.

Different forms (source, object. load) of the same module should be maintained by different people. An audit trail should be maintained such that a load module can be unambiguously related to the associated source module.

Procedures should exist to maintain a consistent relationship between, and to enable the unambiguous association of, different forms. versions and parts (e.g.. specification. test data. source module. object module. load module, test results and user documentation) of a program or procedure. (In the literature this subject is often called configuration management)

Libraries of specifications, test data. test results. procedures, and other documentation should be recorded on structured and responsive media with appropriate functions for update.