The RISKS Digest
Volume 1 Issue 34

Saturday, 4th January 1986

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

C&P Computer Problems Foul 44,000 D.C. Phones
Mike McLaughlin
Putting the Man in the Loop
Jim McGrath
Testing SDI
Jim McGrath
Independent Battlestations
Jim McGrath
Failure probablities in decision chains... independence
Edward Vielmetti
Pharmacy prescription systems
Normand Lepine
Masquerading
Paul W. Nelson

C&P Computer Problems Foul 44,000 D.C. Phones

Mike McLaughlin <mikemcl@nrl-csr >
Sat, 4 Jan 86 13:52:34 est
(Excerpted from Washington Post, Friday, 3 Jan 86, pp D1 & D4)
    By Elizabeth Tucker, Washington Post Staff Writer

    Up to 44,000 business and residential phone lines in the District 
(of Columbia) did not work or worked intermittently (Thursday, 2 Jan 86) 
because of computer problems at Chesapeake & Potomac Telephone Co. (C&P)
    C&P... said the ... company had equipment trouble in its central 
office... between 2:20 and 4 pm.  The problem was fixed when (the company)
shut off connections to the 44,000 lines for a split second, and then 
turned the connections back on.  
    C&P has more than 780,000 phone lines in (DC). 
    (For) nearly two hours... customers often were unable to make or 
receive calls... The telephone company had not diagnosed the precise 
cause of the problem late yesterday....
    Neither the White Hourse nor the General Services Administration...
reported problems...
    (GWU) Hospital experienced a delay in getting dial tones, but only 
for about 10 minutes... 
    ...the Associated Press... could receive calls but not make them 
between 2 and 4 pm.... 
    "You don't know what's going on in terms of news... I thought 
someone cut the cables.  I was worried." (AP spokesman)  
    The Washington Post Co. also experienced problems... 
    One State department official ... "... heard corridor gossip 
[that people] weren't getting calls in or out."  
    The DC police... reported no problems in receiving 911 emergency 
calls, and sid there was no appreciable drop off in calls... C&P... said 
some people may have experienced problems reaching 911... "It could be 
that no one had problems with 911."...
    The problem is not considered usual... "They don't know what caused
the problem, but it's up and working fine . . . For all intents and purposes
they reset the system, turned off all the connections and then turned them 
back on again — LIKE RESETTING A COMPUTER." (EMPHASIS supplied) 
    "They are researching and analyzing the tapes to see what caused 
the problem."... such problems can occur when heavy calling is taking place
... but that such was not the case (2 Jan 86).  
    "We ruled it out . . . A lot of people aren't working downtown... 
calling volumes are down dramatically."  The telephone system "sometimes
can get confused," and think there is heavy calling when there isn't...
            # # # 
(parentheses and close up ... are mine) 
[brackets and spaced . . . are the Post's, as are "quotes"] 
I restrained myself from editorial comments, except where I just had to go 
all caps for emphasis.   Mike McLaughlin


Putting the Man in the Loop

"Jim McGrath" <MCGRATH@OZ.AI.MIT.EDU>
Thu 2 Jan 86 21:43:54-EST
I found the calculations involving SDI reliability interesting.  As
well the debate on SDI software.  But it appears as if people may be
making some aspects of the problem too hard.  Hoping that I have not
missed this part of the conversation....

Obviously some problems (precise aiming of weapons for instance)
demand computer control.  And the time constraints involved in boost
phase interception may require computer control.  But other aspects
(such as initial activation of weapons for mid-course and terminal
phase interception, target discrimination, neutralization of
counter-measures) could be made with substantial human input.  Thus no
need for monster AI programs to cope with all possible contingencies -
humans are ready made for that purpose.

The model to think of is a sophisticated computer game.  The human
operator(s) would take care of truly strange cases (rising moons,
flocks of interplanetary geese) and either determine strategy and/or
provide input parameters for the actual computer controllers (e.g.
"Looks like they are using dummy decoys of the DUMDUM class - better
change certain probabilities in your expert systems target
discriminator in the following manner").  The trade off here is
decreased reliance on sophisticated AI programs that we all concede
that state of the art is not capable of producing and increased
reliance on software that provides an excellent interface to the human
operator.  That would seem to be the easier task (we already have
experience in designing control systems for high performance jet
fighters).

Of course, this increases the problems associated with real time
secure communications, but you were going to have to face them anyway.

Jim


Testing SDI

"Jim McGrath" <MCGRATH@OZ.AI.MIT.EDU>
Thu 2 Jan 86 21:45:01-EST
From Risks, Volume 1 : Issue 33:

> From: horning@decwrl.DEC.COM (Jim Horning)
> - The systems that you cite, and that he cited, are all ones where each
> component is in routine use under the exact circumstances that they
> must be reliable for. No matter how many independent subsystems the
> Lipton SDI is divided into, NONE of them will get this kind of routine
> use under conditions of saturation attack where reliability will be
> most critical. Thus there is a high probability that each of them would
> fail (perhaps in independent ways!).

This seems to be a common problem with any modern weapon system (or
even not so modern - it took WWI for the Germans to realize that the
lessons of the 1880's concerning rapid infantry fire (and thus the
rise of infantry over calvary) did not take artillery development
adequately into account).  But this might be easier to manage than
most.

What if, after suitable advance notice, the SDI system was fully
activated and targeted against one of our periodic meteor swarms?
While not perfect targets, they would be quite challenging (especially
with respect to numbers!), except for boost phase, and CHEAP.  If the
system was regenerative (i.e. you only expended energy and the like),
then the total cost would be very low.

Meteors are just a casual example.  My point is that the costs of
partial (but system wide) testing does not have to lie with the
targets (which many people seem to assume) as much as with weapons
discharge - which may be quite manageable.

Jim


Independent Battlestations

"Jim McGrath" <MCGRATH@OZ.AI.MIT.EDU>
Thu 2 Jan 86 21:45:43-EST
From Risks, Volume 1 : Issue 33:

> From: Herb Lin <LIN@MC.LCS.MIT.EDU>
<> From: horning at decwrl.DEC.COM (Jim Horning)
<> More generally, I am interested in reactions to Lipton's proposal that
<> SDI reliability would be improved by having hundreds or thousands of
<> "independent" orbiting "battle groups," with no communication between
<> separate groups (to prevent failures from propagating), and separately
<> designed and implemented hardware and software for each group (to
<> prevent common design flaws from affecting multiple groups). 
> That is absurd on the face of it.  To prevent propagation of failures,
> systems must be truly independent.  To see the nonsense involved,
> assume layer #1 can kill 90% of the incoming threat, and layer #2 is
> sized to handle a maximum threat that is 10% of the originally
> launched threat.  If layer 1 fails catastrophically, you're screwed in
> layer #2.  Even if Layers 1 and 2 don't talk to each other, they're
> not truly independent.

True but his solution WOULD reduce the probability of the propagation
of "hard" errors (i.e. corrupting electronic communications), and the
whole independence approach should lead to increased redundancy so as
to deal with "soft" propagation of errors such as you cite.

Remember, you do not need to PREVENT the propagation of errors, just
reduce the probability enough so that your overall system reliability
is suitably enhanced.  I think the approach has merit, particularly
over a monolithic system, and should not be shot down out of hand.

Jim


Re: Failure probablities in decision chains and decision independence

<

Please report problems with the web pages to the maintainer

x
Top