Saturday, March 22, 2014

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.


Thursday, March 20, 2014

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.


Wednesday, March 19, 2014

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 mintent can be readily determined and s o  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.

Thursday, December 12, 2013

CO-TRAVELER and Secret Government

Last week The Washington Post reported on a program that the NSA calls CO-TRAVELER.  Under this program, the NSA collects and stores geo-location "meta-data" from cellular service providers.  "The NSA claims that Executive Order 12333 allows the agency to collect cellphone location data, generating up to five billion records every day."  http://www.wired.com/threatlevel/2013/12/nsa-cell-site-data/

When I saw the report, I forwarded the link to two colleagues retired from the NSA.  One of them told me that the NSA did not create this capability but was only exploiting data that the carriers collected so that they could provide the emergency services (fire, rescue, police) with the geographic origin of 911 calls.  It may well be that NSA did not create the capability but they did create CO-TRAVELER, the program.  I seem to recall that the privacy advocates (e.g., ACLU, EFF, EPIC) speculated on precisely this "misuse" when this application to 911 was first discussed.

Note that the NSA does not use this capability in the same way that the emergency services do.  They are not so much interested in the origin of calls in real time.  Rather, they are interested in who may be geographically associated with a target individual in the past.  As in the so-called 215 program, the NSA collects all the data and stores it for an undisclosed period of time.  As in 215, the NSA asserts that they simply collect all this data on speculation, "on the come,"  that they hardly ever query it, that they are not looking at associations in general but only for associations to specific target individuals, and that there are controls in place to resist misuse and abuse.

(I am not the only security professional to assert that the mere existence of such a capability all but guarantees abuse and misuse.  Edward Snowden has demonstrated the limitations of these controls.  The only difference between Snowden and the other rogues in NSA is that he went public.)

This capability is not the problem.  The program is not the problem.  Surveillance is not the problem, at least not yet.  Secrecy and deceit are the problem.  This is one more example of the class of programs the very existence of which the administration repeatedly denied last spring.  While one can make a case for classifying sources and methods, secret government programs are antithetical to the Rule of Law.  That is a distinction that appears to have been lost on President Obama and Directors Clapper and Alexander.  



Wednesday, October 16, 2013

The Bank Secrecy Act

Recently BankInfoSecurity e-News reported that "A U.S. District Court in North Carolina last month dismissed its case against $2 billion CommunityOne Bank after the bank agreed to pay $400,000 toward restitution to victims of a third-party ponzi scheme that operated through accounts maintained at the bank."  The bank was being prosecuted under the so-called Bank Secrecy Act.

Orwell warned us that laws would be misnamed in order to make them seem less repressive. One might be led to believe that a law called the "Bank Secrecy Act" would punish banks for violating the confidence of their customers. Not so. Instead what is does is immunize the banks from liability when, and only when, they snitch on their customers, and as in this case, punishes them severely when they fail to do so.

The regulators would have you believe that this is in the interest of resisting the funding of terrorists, or even as in this case, fraud. Again, not so. While it may occasionally do one of those things, it is really in the interest of tax collection.

Privacy is dead. Your bank is not on your side. Now you understand the popularity of a thinly traded and volatile currency like Bitcoin.

Monday, October 14, 2013

The Price of Liberty

I recently received the following from a colleague.

"In the past few weeks some spirited discussions have sprung up amongst crypto spirits.

The consensus seems we can't even agree on how to secure, or implement, our existing Internet crypto architecture, let alone design and deploy one against Sovereign surveillance."


I was prompted to write:

The broader the application of crypto, the less effective but the more threatening to the governing class.

Crypto cannot protect us from the surveillance state.  We need both law and transparency to do that.  However, the pervasive use of crypto increases the state's cost and decreases its efficiency.

The state can read any message that it wants to; it cannot read every message that it wants to.  Every message that it reads, every person that it watches, is at the expense of another that it does not.  However, as the price of technology continues to fall, they will automatically increase their scope.  They will do so without any motive or intent but only because that is what bureaucrats do.  They believe that whatever they can do, they must.

That the effectiveness of crypto is limited in resisting state surveillance, is no reason not to use it.

All that said, I am not very sanguine.  The American people are fearful and their leaders weak.  The idea of a zero-risk society, based upon cheap technology, is too tempting for either to resist.

"The price of Liberty is eternal vigilance." The battle goes on, never fully lost or won.  Never surrender.