Good Security Practices for Programs

This is the first 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 computer programs, the instructions to a computer as to how it is to proceed.

A program should be limited in size and scope (e.g.. 50 verbs, one ( 1 )  page of source code. 2K bytes of object code) or  be composed of such programs.

A program should be limited in complexity, i.e.. should employ limited .control structures, (e.g.. SEQUENCE. IF-THEN-ELSE. DO-WHILE.  and CASE),. be limited in the total number of paths, and the paths (may embrace but) should not cross each other.

A  program should be written in a language appropriate to the application and employ mnemonic symbols.

A program'should be predictable in result. use or  effect. i.e.. it must be rigorously specified and obvious in its intent.

A program or  procedure should be clearly distinct from its data so that its intent can be readily determined and so  that it can avoid contamination by its data (i.e.. must not modify itself, must not contain embedded constants).

The specification must be complete. It should describe the anticipated output or  response for all anticipated inputs or  stimuli. It should also describe the output or result (e.g.. error message) for all unanticipated input or stimuli.

A specification should include the test data.

The specification must describe all relationships (data and control flows) between a program and its environment.

A program or process must pass to other processes in its environment only those resources (data or  other processes) that are consistent with its specification. To  the extent that the resource to be delivered is variable. Mechanisms must be included to permit only management or the resource owner to control what resource is passed.

A record must be made (in a journal, log. or  data-set) of all communications (event and content, stimulus and response) between a program and other processes in its environment (users. operating system access methods, data base manager.)

All communications between a process and its environment should contain enough redundancy (e-g.. parity bits, counts. longitudinal redundancy checks. hashing codes. control totals. feedback. acknowledgements. confirmations. etc.) to enable the receiving process to recognize that data has been lost. added or  modified. and to fix accountability and facilitate corrective action. The amount of redundancy required is a function of the reliability of the process. (Consider. for example, a hardware process. a software process. and a user. More redundancy is indicated for communication with another program than for communication with hardware and less than for communication with a user.)

A failed communication between the program and other processes in its environment must be recognized.
In the presence of an indication of a failed communication between the program and another process in its environment, a program must attempt corrective action (e.g., repeat the exchange); failing that, it must communicate the failure to at least two other processes (e.g.. log and console or log and user).

The use of a program or procedure must be recorded with reference made to the user. Where this service is not provided by a superior process. the program itself should provide it.