Thoughts for the White House

The idea of this post is not so presumptuous as it might seem.  I had a note from John Podesta on White House e-stationery asking for my thoughts.  In the interest of transparency, I thought I would share them with you.


Under the Rule of Law, the citizen surrenders to the state the exclusive right to the use of force in return for severe restrictions on all other powers of government and transparency and accountability.  Since WWII, and particularly since 9/11, in the name of "national" and "homeland" security, the activities of government have become increasingly powerful, intrusive, and secret to the point that they violate this fundamental social contract.  The governing classes appear to have a morbid fear of the citizens and see us as the "enemy," not to be trusted.

There must be no secret government.  It is antithetical to any idea of self-government.  Since databases are instruments of government, there must be no secret databases.

We must forgo any intelligence that we cannot collect through transparent and accountable means.  While we may not have to know sources, methods, or results,  there can be no secret programs.  There must be protection of whistle-blowers; the government must avoid even the appearance of persecution.  The government must assume full responsibility to keep its secrets; it may not make it a crime to report those secrets when it fails to keep them.  There must be swift and certain punishment of public officials who mislead, lie to,  or conceal from Congress and the people.  (It is past time for Directors Alexander, Brennan, and Clapper to retire with their honor in tact.)

The government must admit that it "knows" and is accountable for all use, misuse, and abuse of any data that it collects or stores.  The excuse that "we do not look at it" does not reassure; the mere collection and possession is intimidating.  The citizen cannot be said to consent to a government of which he lives in perpetual fear.

The government must admit that it has no right to claim a power for itself just because Google has it.  Google does not have guns, tanks, drones, nukes, or even dogs.  Our contract with Google may be just as asymmetric as the one that we have with government but it is different.

The government must forgo the use of other governments or agencies to avoid the restrictions of the Fourth Amendment.  A search is no less "unreasonable" because it is conducted by the United Kingdom, AT&T, Citibank, Cablevision, or a private investigator.  Information from such sources must not be used  as "cause," "probable" or otherwise, to initiate investigations or justify warrants.

If the government is going to exploit modern technology, it must admit to its power.  It must admit that at some point a change in quantity represents a change in kind, that a search that is reasonable at one scale may be unreasonable when amplified by new technology.

The government must admit that it cannot use the departments of Defense, Homeland Security, or Justice to usurp the police powers reserved to the states and municipalities.


They asked me for my thoughts.  I gave them my thoughts.

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.

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.

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.