Text File

Date: Mon 9 Sep 85 20:40:51-PDT From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA> Subject: RISKS-1.9, 09 Sep 85 Sender: NEUMANN@SRI-CSLA.ARPA To: RISKS: ;

RISKS-FORUM Digest Monday, 9 Sep 1985 Volume 1 : Issue 9

FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS Peter G. Neumann, moderator

Contents: McCarthy, Weizenbaum on SDI (Douglas Schuler) Why I'm against even a reliable SDI (Jeffrey Mogul) Risk Assessment and Risk Management (Edward V. Berard) Risks in displaying a file containing control characters (Keith F. Lynch)

[*** Apologies to those of you who have been suffering from INDIGESTIFICATION. The blank line before the following 70 hyphens makes the difference, and your undigestification programs should now work on RISKS! PGN ***]

(Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA) (FTP Vol 1 : Issue n from SRI-CSL:<RISKS>RISKS-1.n)

----------------------------------------------------------------------

Date: Mon, 9 Sep 85 09:34:15 pdt From: bcsaic!douglas@uw-june (douglas schuler) To: RISKS@SRI-CSL Subject: McCarthy, Weizenbaum on SDI

Joseph Weizenbaum states that he would be against SDI "even if it worked." I agree. The premise that "IF the SDI could work, then we must have it (at any price)" is naive. It seems that many people are willing to accept that premise hoping that it will anchor the discussion in the technical area.

One factor which is rarely addressed is that of intermediate systems which the SDI will spawn. There is a tendency to think of the SDI system as being one big system that one day appears overhead as a whole, integrated system. I have little doubt that the SDI plan includes many deliverables along the way. These intermediate systems will both be arguably non-defensive and pose a large problem for integration. I.e., the system must not only be trustworthy when "fully deployed" but at a multitude of intermediate steps. Thus risks will exist in advance of the full delivery (if there ever is to be one).

Another factor is the so-called defensiveness of the system. If two people are armed with guns and one suddenly dons a bullet proof vest this act will be perceived as an offensive act.

Pro-SDI people almost always accuse SDI critics of being politically motivated. Given the immense (and possibly impossible) technical task of getting the system to work, and the guarenteed proliferation of offensive weapons (designed to penetrate the system), it is very, very difficult for me to believe that the pro SDI folk are not motivated primarily from political (and economic!!) grounds.

- Doug Schuler

------------------------------

Date: Mon 9 Sep 85 16:40:02-PDT From: Jeffrey Mogul <MOGUL@SU-SCORE.ARPA> Subject: Why I'm against even a reliable SDI To: risks@SRI-CSL.ARPA

To quote from RISKS Vol 1 #8: 2. I can disagree only with one aspect of Weizenbaum's contribution. He says that he would be against SDI even if it would work, but his arguments mainly show even more reasons why it won't "make nucelar weapons impotent and obsolete." It is probably useless to argue about how we would feel about the system if it would work, but I feel the decision would be much harder to make than it is now. [Dave Parnas]

I think this touches on the crux of the matter: what problem is SDI meant to solve? If we could guarantee that SDI would not only "make nuclear weapons impotent and obsolete", but would in fact reduce the risks associated with war (not necessarily the same thing) then I would not be against SDI. However, I argue (and I suspect this is Weizenbaum's point, too) that an SDI that worked according to the current specification would actually increase risks, even though the system performed "flawlessly".

This is not the place to discuss the strategic implications of SDI, but I think it's important to realize that there are those of us who believe both that SDI is not likely to meet its current specification, nor that it would be a good idea even if it did.

[I] would see some truth in the argument that the non-technological solutions also have a clear risk of failure. [Parnas]

I am afraid that there is no failure-proof solution, technological or not, to the problem of "war". John McCarthy is right that we must compare the risks of the technological solution (e.g., SDI) to its non-use. My fear is that, in this case, the problem is not that the use of technology might fail to solve the problem, but that it might actually make things worse.

------------------------------

Date: Mon 9 Sep 85 08:16:07-PDT From: Edward V. Berard <EBERARD@USC-ECLB.ARPA> Subject: Risk Assessment and Risk Management To: risks@SRI-CSL.ARPA

There has been some discussion of comparing alternative risks on the RISKS mailing list lately. For example, what is the risk associated with the introduction of a new technology versus not introducing the technology? Risk assessment and risk management need not be "guesstimates" nor "a number picked out of the air."

The insurance industry has had to assess and manage risks for years. In fact, they have made quite a science out of these two areas. I would recommend that those who wish to find out more about risk management and risk assessment read:

RISK MANAGEMENT AND INSURANCE, Fourth Edition, by C. Arthur Williams, Jr. and Richard M. Heins, McGraw-Hill, 1981.

Don't let the title put you off. Virtually the entire book is dedicated to risk management, with only a few pages on insurance. You will also find that there are entire professional societies dedicated to managing and assessing risk, e.g., the American Risk and Insurance Association and the Risk and Insurance Management Society.

-- Ed Berard EBerard at ECLB (301) 251 - 1626

------------------------------

Date: Mon, 9 Sep 85 00:26:04 EDT From: Keith F. Lynch <KFL@MIT-MC.ARPA> Subject: Risks in displaying a file containing control characters To: LIN@MIT-MC.ARPA cc: Risks@SRI-CSL.ARPA, Security@RED.RUTGERS.EDU

Date: Sun, 8 Sep 85 16:40:44 EDT From: Herb Lin <LIN@MIT-MC.ARPA>

My naive model is that I have a special program that intercepts the raw bit stream that comes in from my communications port. It then translates this into ASCII, and then prints it on my screen.

If this is all that my program does, I can't see what harm can be done.

Several kinds of terminals are programmable from the host, in that certain escape sequences can be sent to them to get them to perform actions such as defining the terminal's function keys.

If a user inserts the appropriate escape sequences in a mail message to his system manager, or into a file which will be displayed by the manager, when the manager reads that mail message it will reprogram a function key on the manager's terminal, which the manager may have programmed to do some common harmless function, to instead do some other command such as give the user unauthorized privileges.

This is a fairly well known bug, and many mail systems are now protected against it, in that they will not transmit any control characters or escape sequences to the terminal.

The moral is that there are many subtle ways to break security, and even things that seem to be quite safe may not really be. ...Keith

------------------------------

End of RISKS-FORUM Digest ************************ -------