risks@sri-csl (09/10/85)
From: RISKS FORUM (Peter G. Neumann, Coordinator) <RISKS@SRI-CSLA.ARPA>
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
************************
-------