Boris Beizer, "Software Testing Techniques", 1983

Boris Beizer was an influential figure in the field of software testing. His book Software Testing Techniques, across three editions, is often-cited. When the first edition was published in 1983, security was still focused more on operating systems and database integrity than on applications, so it's maybe ahead of its time that the topic appears in the index at all.

On this page Beizer recommends modeling "High-level control functions within an operating system. Transitions between user states, supervisor's states, and so on. Security handling of records, permission for read/write/modify privileges, priority interrupt and transitions between interrupt states and levels, recovery issues and the safety state of records and/or processes with respect to recording recovery data." So he's still talking about the operating system.

But that's not the only place he talks security. On page 17 in the chapter "The Taxonomy of Bugs", he notes that "Gratuitious enhancements [in functionality] can, if they increase the system's complexity, accumulate into a fertile compost heap that breeds future bugs, and they can burrow holes that can be converted into system security breaches."

Chapter 7, Data Validation and Syntax Testing, is devoted to the hazards of failure to sanitize inputs. He opens with:

I think one of the worst cop-outs ever invented by the computer industry is "garbage-in equals garbage-out". We know when to use that one! When a program of ours screws up in a nasty way. People are inconvenienced by the host of subsidiary problems that result. A big investigation is launched and it's discovered that an operator made a mistake, an improper tape was mounted, or the source data was inconsistent, or something like that. That's the time to put on the Guru's mantle, shake your head from side to side, disclaim all guilt, and mutter, "What do you expect? Garbage-in equals garbage-out." 

Do we have the right to say that to the families of passengers on an airliner that crashes? Will you offer that explanation for the failure of the intensive care unit's monitor system? How about a nuclear reactor meltdown, a supertanker run aground, or a war? GIGO is no explanation for anything except our failure to install good data-validation checks, or worse, our failure to test the system's tolerance for bad data. The point is that garbage shouldn't get in at all -- not in the first place or in the last place. Every system must contend with a bewildering array of internal and external garbage, and if you don't think the world is hostile, how do you plan to cope with alpha particles?

Of course input validation is fundamental today. But Beizer is not finished predicting the future:

There are a few malicious users in every population -- infuriating people, professional Blue Meanies who delight in doing strange things to the systems they use. Years ago they'd pound the sides of vending machines for free sodas. Their sons and daughters invented the blue-box used to get free long-distance and international telephone calls. Now they're tired of probing the nuances of their home video games and they're out to attack computers. They're out to get you. Some of them are even programmers. The are persistent and systematic. A few hours of attack by one of them is worse than years of ordinary use and bugs found by chance. And there are so many of them; so many of them and so few of us. 

Then there is crime. It's estimated that computer criminals (using mostly hokey inputs) are raking in hundreds of millions of dollars annually. Some criminals could be doing it from a telephone booth in Arkansas with an acoustic coupled programmable calculator. Every piece of bad data unknowingly accepted by a system, every crash-causing input sequence, is a chink in the system's armor that knowledgeable criminals can use to penetrate, corrupt and eventually suborn the system to their own purposes. And don't think the system's too complicated for them. They have your listings, and your documentation, and the data dictionary, and whatever else they need. There aren't many of them, but they are smart, highly motivated, and possibly organized.

Beizer was an interesting and challenging individual by many accounts. His writing style makes the material more entertaining than the title suggests.

Stockton Gaines and Norman Shapiro, "Some Security Principles and Their Application To Computer Security" (1978)

Presented at Foundations of Secure Computation, an October 1977 conference at the Georgia Institute of Technology. Gaines and Shapiro begin by adapting basic security principles -- barriers, detection, concealment -- to computers. They also consider deterrence in light of an intruder's motives, with an eye toward making the intrusion too difficult to bother.

It is important to consider security from the point of view of the potential violator. He may seek to obtain information of value to him or to modify information that somebody else will use because there is some expected value to him as a consequence of the modification. He may be dissuaded from doing so because he estimates that the costs are unacceptable. The first cost is the direct cost in time, effort, and money of carrying out his plans. Both strong protection mechanisms and concealment mechanisms, such as cryptography, may impose unacceptable costs in one or more of these measures. In addition, detection and apprehension may have costs associated with them that are uncertain to the violator but whose deterrence value may be substantial. The violator may be deterred by the social stigma associated with the detection or by the penalties which may follow as a consequence of detection.

Next they consider contemporary computer security, comprising authentication, authorization ("access control mechanisms"), and the operating system, as well as the system hardware. The idea of holes in an application's security has not yet caught on.

To understand the state of computer security today and how it might be enhanced, we first analyze computer systems from a system point of view. A person attempting to use a computer system either by submitting a job or accessing the computer through a terminal must identify himself to the computer and then be authenticated. ... Other aspects of a computer system which are relevant to security are the hardware itself and the operating and management procedures for the computer.

... When the question of the security of information stored in a computer system was first raised, over a decade ago, it was immediately discovered that from a security point of view operating systems were full of flaws (and many of them still are today). In some systems, these flaws were so serious that it was possible for a user to gain control of the operating system, that is, to have code prepared by the user executed as if it were the supervisor code. Furthermore, flaws in the operating system, once discovered, turned out to be easy to exploit. ...

The initial reaction to the discovery of the weakness of computer system security was to try to correct the flaws. This meant rewriting the access control code so that it would work correctly and trying to rework those parts of systems for which flaws were due to bad design. Such efforts did not work out well; systems so enhanced were shown to have many flaws remaining. Because these flaws were easy to exploit, covering up only a few of them did not appear to be very advantageous. As a result of these failures, recent research has been directed to finding new operating system designs which take security into account in a fundamental way during the design process. ...

They note the relative absence of detection mechanisms for security, and close with a recommendation for what would today be recognized as logging:

There are currently few examples of the use of detection in computers. One that is frequently used in systems providing remote access via terminals is to report to the user at each log-in the time of his previous log-in. Thus providing him the opportunity to notice if this report differs from what he remembers. This technique may cause the detection of unauthorized use of the account. There are some weaknesses. For instance, users who repeatedly see the log-in message reporting time of last use soon fail to read this information. ... 

We have already remarked that the notion of detection has received very little attention. As an example of the kinds of techniques that might be used, we will consider one idea -- that a record be maintained of all accesses to a file owned by an individual that are made by others, or of only those accesses that are made by others when he is not logged into the system, and that this information be reported to him. Ultimately, the user may provide a list of those he expects to access his files and the report may consist of information concerning all accesses by those not on that list. If such information is stored in a way that a violator cannot get at it, then the information can be relied upon a great deal of the time. One way of recording information so that it cannot be destroyed is to write it on a tape that has no backspace provisions. ...

Interesting and worth a read. The PDF of the entire conference proceedings is linked above. I also found a hardback copy for a few bucks on Amazon.

The Computer and Invasion of Privacy (1966)

In 1965, a National (or sometimes, Federal) Data Center was proposed, which would permit centralized management of statistical data collected by various U.S. federal agencies. The goal was wider availability and better correlation of statistical population data for social science researchers. The evolution and ultimate failure of the proposal is documented by Rebecca S. Kraus.

The House Committee on Government Operations heard testimony on July 26 - 28, 1966 about the the proposed Center and its potential privacy risks. Some remarks from Paul Baran are in line with modern security practice.

If the computer industry is to avoid external regulation, then it behooves everyone who is involved with time-shared systems handling potentially sensitive information to start working, or a[t] least thinking, about the problem of privacy. The computer industry should take the initiative and the responsibility of building in the needed safeguards itself before "Big Brother" is forced to do it himself...

To be more specific, what safeguards do I envision? Of course, we do not know all the answers yet. But, clearly, there are steps that we should be considering, including:

Provision for minimal cryptographic-type protection to all communications lines that carry potentially embarrassing data -- not super-duper unbreakable cryptography, just some minimal, reversible, logical operations upon the data stream to make the eavesdropper's job so difficult that it isn't worth his time...

Never store file data in the complete "clear." Perform some simple -- but key controllable -- operation on the data so that a simple access to storage will not dump stored data out into the clear. 

Make random external audits of file operating programs a standard practice to insure that no programmer has intentionally or inadvertently slipped in a "secret door" to permit a remote point access [to] information to which he is not entitled by sending in a "password."

When the day comes when individual file systems are interconnected on a widespread basis, let us have studied the problem sufficiently so that we can create sensible, precise ground rules on cross-system interrogation access.

Provide mechanisms to detect abnormal informational requests. That is, if a particular file is receiving an excessive number of inquiries or there is an unusual number of cross-file inquiries coming from one source, flag the request to a human operator.

Build in provisions to verify and record the source of requests for information interrogations.

Audit information requests and inform ·authorities of suspected misuse of the system.

This is followed by some discussion on aggregated and anonymized ("statistical") information vs. personally-identifiable information, and how personal information might be protected by legally-mandated system design.

Mr. HORTON. [I]s it possible technically to design a system so that only statistical information could be utilized or be furnished and thus protect the-so-called individual information?  

Mr. BARAN. If you say I know all the questions I want to ask in the future, perhaps. But if you don't, that means you have to keep the information in raw form. This is the most efficient way of keeping it. 

Mr. HORTON. I am assuming you are an expert in this field (the field of computers and what they can do. I am asking you from a technical standpoint whether or not it is possible -- in other words, could we pass a law that would require the construction of a computer that would only produce statistical information that would be foolproof insofar as individual information was concerned?

Mr. BARAN. "Foolproof" is a rough word. I think we could build safeguards to make it difficult. How effective they are, I think, requires a level of detail that we have not examined yet. 

Mr. HORTON. The point I am trying to make is that I think any law Congress would enact to safeguard the right of individuals in this area would depend to a large measure upon the state of the art. 

Mr. BARAN. That is right. 

Mr. HORTON. With regard to the technical aspects, I do not think we have sufficient information to protect the private individual in the computerized systems. 

Mr. BARAN. That is right. The technical art is changing very rapidly in computers. The speed of the computer is going up tremendously. The cost is coming down. The size of the memories is expanding very rapidly. As we look to the future we could probably see increases of size of computers -- perhaps on the order of 10,000 times as powerful as today's computers.