Good Security Practices

In the early 1980s I published some recommendations on "Good Data Processing Security Practices." Because "publication" then was not the same as it is today, I plan to reprise those recommendations here over the next several weeks,

The recommendations are based upon the following propositions:

1) Risk is lowered when multiple people are involved in sensitive functions;

2) Risk is minimized when each individual has access to only those resources required to do their jobs
(rule of "least possible privilege");

3) Sensitive activity should be independently authorized;

4)  Duties should be assigned in such a way and records kept such that individuals can be held accountable for their actions;

5) Duties should be assigned such that one person doing his job acts as a check upon those in his environment and is checked upon by them;

6) No one should have access to sensitive combinations of resources.

It is not for me to justify or defend these propositions;   I did not originate them.   Rather they are the controls first articulated by the "little monks" who originated double entry bookkeeping.  While one might be tempted to dispute with the monks, they are long since dead; the ideas survive them.   While I will not defend them, I will be happy to explain or clarify.

I will make recommendations on the application of these principles to programs, libraries of programs, the process of programming, those who engage in the process, and those who use the programs.  Finally, I will make recommendations on their application to systems.

Unlike the principles, I did articulate the recommendations.  While I assert that they follow from the principles above, that is at least arguable.  Therefore, I stand ready to defend them.

Some of the ideas may seem inconsistent with contemporary or common practice.  As I will point out in a few places, all of the recommended controls are subject to considerations of scale. Even with those caveats, I think that you will still find some useful ideas.