Monday, May 5, 2014

Good Security Practices for Programming

This is the one 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 programming, the processes, including management, by which programs are produced. 


Procedures should exist for enforcing adherence to rules. standards and
conventions (see Good Practice for Programs). Such procedures should be
sufficiently rigorous to make variances and anomalies obvious to management.

Procedures should exist for enforcing separation of duties and involvement
of multiple people (see Good Practice for Programmers).

Procedures should exist for requiring and recording the approval and
authorization of user and development management. These may be forms
or other procedures external to the system. or transactions or procedures
internal to it which can be invoked only by the designated managers.

Procedures should exist for maintaining the integrity of module and version
names. (see good practice for program libraries).

Procedures should exist for maintaining a record of the creation and
modification of all programs, The record should contain the content of the
change and references to the programmers. the date and time and the
process used.

Procedures should exist for reconciling the program to the specification.
These should include tests. independent review,s and structured walk-throughs.

Procedures should exist for maintaining a record of the results of all test.
review, and walk-through results.

Procedures should exist for requiring and recording the acceptance of user
management.

Procedures should exist for reconciling resource consumed (e.g., programmer
time. computer time) with expectation.


These procedures can effectively be built into the forms. editors. compilers.
library managers. and test drivers and other tools used by programmers, librarians. and
management.

The Obama White House Response to Internet Vulnerabilities

The White House has responded to recent reports that the NSA knew about and exploited the Heartbleed vulnerability rather than fixing it.  While denying the report, the White House pointed out that the choice is not quite so obvious as it might seem.  They assert that the narrow intelligence or investigative advantage from the exploitation of the vulnerability might trump the broader security advantage of fixing it.

"Governing is about making (often difficult) choices."
This is a particularly troubling space. There has been a dramatic loss in public trust and confidence in government over the last two administrations. "National Security" and "investigative necessity" have contributed to that loss.  Not only do they cover a multitude of sins, they are often used for that purpose. Finally, neither the NSA nor the FBI tell the White House everything they know or do. Indeed, in pursuit of "plausible deniability," both agencies often keep their own leadership in the dark.
We are not going to,reform these agencies as long as the current leadership remains in place. While Alexander has retired, Brennan, Clapper, and Holder would be justified in concluding that they are doing the right thing and ought to do it harder.
I do not advocate public disclosure of vulnerabilities. "Heartbleed" and the recent Internet Explorer vulnerability demonstrate that the angst surrounding such disclosure is often more costly than the risk of the vulnerability. However, quiet and immediate notification of the developers, distributors, and those others best able to,close it, should be the default. Indeed, many of these vulnerabilities are so pervasive that even the best we can hope for in closing them will leave a big window in which the government can exploit them for its other purposes, legitimate and otherwise.

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.