RISKS@CSL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (10/24/86)
RISKS-LIST: RISKS-FORUM Digest, Thursday, 23 October 1986 Volume 3 : Issue 85
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
On the Risk of Discussing SDI (Craig Milo Rogers)
SDI Impossibility (Douglas Humphrey)
Swedish Vulnerability Board Report on Complex System Vulnerabilities
(Chuck Youman)
Re: Thresher (David Feldman)
Stealth and ATC (Dan Melson)
Inoperative components (Peter Ladkin)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious. Diversity is welcome.
(Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM)
(Back issues Vol i Issue j available in CSL.SRI.COM:<RISKS>RISKS-i.j.
Summary Contents in MAXj for each i; Vol 1: RISKS-1.46; Vol 2: RISKS-2.57.)
----------------------------------------------------------------------
Date: 23 Oct 1986 17:52:08 PDT
Subject: On the Risk of Discussing SDI
From: Craig Milo Rogers <ROGERS@B.ISI.EDU>
To: Risks@CSL.SRI.COM
The moderator recently requested intelligent open discussion
relating to computers and related technologies in SDI. I believe that
there has instead been too much discussion of computers and SDI.
The hardware and software issues raised by Parnas and others are
interesting. They are complex, they defy simple quantification, and they
relate directly to the work of many of the readers of this digest.
Yet, there are much simpler and more easily discussed problems with
SDI. SDI provides minimal protection to Europe. SDI does not appear to
provide protection against nuclear weapons launched at the US from off-shore
submarines. Bombs can be smuggled into the US via, say, Canada, and
reassembled in the hearts of our cities. Clearly, if you heed these
arguments, SDI in no way makes nuclear waepons "impotent and obsolete".
By focusing our attention and that of the general public on
computer-related SDI arguments, we run the *risk* of diverting attention
from more important issues. We as computer technologists are raising the
(weak, esoteric) issues with which we are familiar, when we as intelligent,
informed citizens should be raising more general questions (perhaps
precisely because we *are* less familiar with them).
There is a risk in introducing computers into a discussion in
which they are not really relevant. It is not enough to be able to
discuss an issue intelligently. One must also know when it is
intelligent to raise the issue in the first place. (By the way, it is
not clear to me that this message qualifies, either).
Craig Milo Rogers
[This issue reaches a relative high mark for noninclusion of messages,
as I have omitted several on this topic. However, this one gets accepted
-- because it is sound, objective, and coherent, and does not violate
the other requirements. I have stated before that it is impossible to
draw a line around "computer relevance". Craig's point is well taken.
By the way, I squelched the discussions between Michael Scott and
Andy Freeman (plus a comment from Herb Lin) which were getting to
third-order arguments and re-reinterpretations. (Both of the main
participants still feel they have further clarifications to make.)
However, I urge you all to take more care in your INITIAL statements.
That can do wonders at staving off lengthy iterations. PGN]
------------------------------
Date: Thu, 23 Oct 1986 08:47 EDT
From: LIN@XX.LCS.MIT.EDU
To: Douglas Humphrey <deh@ENEEVAX.UMD.EDU>
Cc: arms-d@XX.LCS.MIT.EDU, risks@CSL.SRI.COM
Subject: SDI Impossibility
From: Douglas Humphrey <deh at eneevax.umd.edu>
SDI Impossibility? - I have a good background in physics, computing
(software and vlsi hardware) and a lot of DEW (Directed Energy
Weapons), and I have yet to hear ANYONE explain WHY SDI is impossible.
Tell us what you mean by SDI, and it can be explained or not. Every
technical analyst believes it is possible to build something that will
destroy some missiles. No analyst believes it is possible to build
something that will destroy all missiles. The question is whether or not
the ability to destroy some missiles is worth what you must pay to get it.
I hear all this about the complexity of the software, but I used to be
part of a group that supported a software system of over 20 million
lines of code, and it rarely had problems.
But it sometimes did. How much would you have been willing to bet that the
problems would not arise at critical times when you could not do debugging?
we wrote simulators for a lot of the load since we did not want to try
experimental code out on the production machines, but we never had a
simulator fail to correctly simulate the situation.
I'll bet you didn't simulate something with which you had no experience. To
judge what it means to have a simulator run correctly means that you have
some way of judging its correctness. No one has such experience with a real
nuclear war.
There were over 100 programmers supporting this stuff, and it was
properly managed and it all worked well.
Given the current estimates of SDI software size, the total programming team
might be an order of magnitude bigger. 100 programmers would be tiny.
Is someone suggesting that the incoming target stream can not be
simulated ? Why not ? We do it now on launch profile simulations
involving the DEW (Distant Early Warning) network and a lot of other
sensor systems.
But ballistic missile attacks would be straightforward now, because
there are no defenses. If you assume that the Soviets do nothing
differently, then maybe you could (though I personally doubt that).
But the Soviets will react, and what gives you the confidence that you
can predict their new tactics?
Is someone suggesting that PENAIDS (Penetration Aids) can not be
simulated ? Why not ? We do it now also.
Penaids that we know about we can simulate. Penaids that we don't
know about we can't.
Worst case studies just treat all of the PENAIDS as valid targets. If
you can intercept THAT mess, then you can stop anything !
But you can't. Current threat cloud estimates range from a low of
30,000 to a high of a few million. If you spend enough money, you
might be able to kill everything, but it seems unlikely that you can
kill them all with just a few thousand platforms in 20 minutes.
I get the feeling that people are assuming that the SDI software is
going to be one long chunk of code running on one machine and that if
it ever sees anything that is not what it expects its going to do a
HALT and stop the entire process.
No critic has said this. The fear is that it will do something that
it should not do, of which halting could be one thing. The problem is
that you can't predict what that thing will be.
So. The Challenge. People out there who think it is Impossible, please
identify what is impossible. Pointing systems ? Target acquisition ?
Target Classification ? Target descrimination ? Destruction of the
targets ?
The hard thing is not any of these, and it illustrates the primary issue in
software as well. The hard thing is knowing what the Soviets will do; that
places the specification of requirements of our software in their hands, and
they are unlikely to tell us what they will do. You've mentioned essentially
the analog of implementation details -- serious, complicated, hard, maybe
(or maybe not) impossible. But that's assuming a cooperative opponent.
It seems that the real question on which we disagree is one raised by the
recent discussion of Scott's editorial and Freeman's response. Computer
programs handle a variety of inputs, even if we can't specify in precise
detail the exact sequence of bits that are input. However, our ability to
write computer programs that do this is dependent on our ability to formulate
general rules that characterize the essential features and regularities in the
bit stream. That is one reason why writing compilers is easier than writing
automatic translators from English to French; rules for computer languages
are easy, rules for natural language are hard (and maybe impossible).
Similarly, all military systems function in unknown environments, i.e.,
environments that cannot be specified down to the last detail. When these
systems function as expected, the system designers must have correctly
predicted the essential features of the operating environment -- you could
say that they have been able to formulate general rules that characterize
the essential features and regularities of the environment.
Critics of SDI have no faith that it is possible to capture the
essential features of ALL possible Soviet responses to SDI. As a
non-critic of SDI, do you think we can? Or do you think that this
criterion is too strong?
------------------------------
To: risks@csl.sri.com
Subject: Swedish Vulnerability Board Report on Complex System Vulnerabilities
Date: Thu, 23 Oct 86 13:52:32 -0400
From: Chuck Youman <m14817@mitre.ARPA>
The October issue of Signal magazine contains an article by Thomas Osvald on
"Computers, Vulnerability and Security in Sweden." It describes a number of
projects carried out by the Swedish Vulnerability Board. Of particular
interest to RISKS is a project that addressed the vulnerability problems
associated with the complexity of EDP systems. Mr. Osvald writes:
> A system becomes too complex when nobody can intellectually
> understand and comprehend it. Thus, a company will not change a
> system because secondary effects cannot be foreseen. The board
> concluded that one of the problems of conventional, administrative,
> complex systems is that it is difficult or even impossible to
> change these systems in an orderly, controlled way. On the other
> hand, there is a rapid increase in the change rate in our society
> in general and a correspondingly increasing demand for flexibility
> in information systems.
> Therefore, it must be accepted that programs are for standard or
> nonrecurrent use with an ever shorter life expectancy. However,
> data that are the raw material of information will not change as
> quickly as the processing rules. Data are therefore the resource
> that has to be cultivated, protected, tended, preserved, and developed.
> This approach supports recent developments of systems design methods,
> such as fourth generation languages, data dictionaries, and data base
> techniques.
Unfortunately, the article does not include a bibliography. Does
anyone out in RISKS-land know if a English translation of this report
exists?
Charles Youman (youman@mitre.arpa)
------------------------------
Date: Wed, 22 Oct 86 02:34:25 edt
From: David Feldman <feldman%dartmouth.edu@CSNET-RELAY.ARPA>
To: Risks@CSL.SRI.COM
Subject: Re: Thresher
A friend of my dad's who served in the submarine service once told me his
"version" of the events on the Thresher:
Water had gotten into a compartment (or at least onto a sensor) in the
reactor unit, and that caused the reactor to scram. (According to him, this
type of shutdown is unconditional and irreversible on USN subs). When the
ballast tanks were blown, for some reason the delivery pressure of the air that
cleared the ballast tanks came in higher than normal, and caused a greater
temperature drop at the valves. The valves froze open, allowing all of the air
to escape, leaving the Thresher defenseless.
Note: this is second hand from one submarine officer.
Dave Feldman
feldman@dartvax.edu
------------------------------
Date: Thu, 23 Oct 86 01:03:13 PDT
From: crash!pnet01!dm@nosc.ARPA (Dan Melson)
To: risks@csl.sri.com
Subject: Stealth and ATC
If it exists, they are hardly going to put it into heavily travelled airspace
over high population areas, where everybody can see it.
As for radar signatures, civilian ATC relies upon a mode 3/a transponder, and
targets are generated on our PVD's (primarily) as a result of that. If they
want the aircraft visible to civil radar, they simply turn the transponder on.
(There are large areas of restricted airspace and MOA's (Military Operations
Areas) where the military does it's own operations without hindering civil
ATC, and if it exists, would guess that most stealth flights are within
such areas)
The above information is non-classified, freely available to any private
pilot.
DM
------------------------------
Date: Thu, 23 Oct 86 18:28:22 pdt
From: ladkin@kestrel.ARPA (Peter Ladkin)
To: risks@sri-csl
Subject: Inoperative components
Doug Humphrey wonders whether aircraft need cockpit warnings to tell of
major failure modes. The answer seems to be yes. Multi-engine aircraft
instructors will tell you that a common occurrence with simulated engine
failures in multi-engine aircraft is for the student to feather the prop on
the good engine. The NTSB notes that this happens for real, too.
Peter Ladkin
ladkin@kestrel.arpa
------------------------------
End of RISKS-FORUM Digest
************************
-------