The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 4 Issue 15

Thursday, 20 November 1986

Contents

o IBM VM/SP SP Cracked
Jack Shaw
o On placing the blame AND Safety-Critical UK Software
Bjorn Freeman-Benson
o On placing the blame
Scot Wilcoxon
o Safety-Critical Software in the UK
Scott E. Preece
o Computer-based stock trading
from Discover
o FAA's Role in Developing a Mid-Air Collision-Avoidance System
Chuck Youman
o Info on RISKS (comp.risks)

IBM VM/SP Cracked

Jack Shaw <JDS2F%UOTTAWA.BITNET@WISCVM.WISC.EDU>
Tue, 4 Nov 1986 22:32:40 EST
It appears someone (student hacker) has cracked VM. Anyone interested
in this should contact their IBM SE about APAR VM26824. Looks like
a pretty serious breach too...Hacker was able to change anyone's CP
class from A-H or their own CP class.
                                         Jack Shaw, Univ. of Ottawa


On placing the blame and Safety-Critical UK Software (RISKS 4.14)

Bjorn Freeman-Benson <bnfb@beaver.cs.washington.edu>
Thu, 20 Nov 86 12:44:36 PST
I do not have a copy of the ACARD report, but judging from Appendix B,
this report attempts to put almost all the blame for computer failures
on the software, rather than the hardware, operation or the combined system.

  >B.3 The fault lies not so much in the computer hardware as in the programs
  >which control them, programs full of the errors, oversights, inadequacies
  >and misunderstandings of the programmers who compose them...

Any system is only as strong as it's weakest link, and so any Certified
software will have to be written, installed, run on and operated by Certifed
people and machines.  But, worse than that, what about interactions between
the software and the hardware, or even other software (like the OS)?  For
example, Certified package A runs on Certified OS B on Certified hardware C.
Something in C fails and B takes care of it, but in doing so response time
falls until A fails (such as running a ship into an oil-rig).  

Certifying software would be a big step forward, but I think that
concentrating on just one part of the whole system will not safely Certify
that system.  For example, reread the past N RISKS where time after time an
operator error has caused problems.  Or look at the real experience that I
based the previous example on:

    We had a PDP-11 (not Certified) in which a board failed sending an
    inordinate number of spurious interrupts to the CPU.  The OS handled them
    all, but response time went down by 80%.

If the system failed that way, who would be held liable?
                                                               Bjorn

   [First, we have been around this question on numerous occasions.  There
    is often NO ONE PLACE TO PUT THE BLAME.  Second, the ACARD report sets
    out to make a strong case for what the UK should do WITH RESPECT TO
    SOFTWARE.  In that context, I don't think the report as a whole denies
    that other factors are not also critical; it just focuses on software.  
    (The rest of the report is certainly of interest to software engineers.
    By the way, don't ask me about how to get copies.  Ask HMSO.  Perhaps
    one of our British correspondents can provide ordering information.)  PGN]


Re: On placing the blame (Peter J. Denning, RISKS-4.14)

rutgers!meccts!mecc!sewilco@seismo.CSS.GOV <Scot Wilcoxon>
Thu, 20 Nov 86 11:35:24 EST
In the [first cited] example, the collision-avoidance method failed because
the air traffic controller could not communicate with the aircraft.  The
present method cannot compensate for jammed radio frequencies, unless the
aircraft are monitoring the international emergency channel and the
controller thinks of trying it.
                   [Observation: Even though the jammed frequency is not a 
                    computer problem per se, it greatly impacts the ability
                    of the computerized ATC system to do its job.  PGN]

Other recent postings have pointed out the centralized characteristic of the
existing collision-avoidance methods preferred by the FAA and compared them
to an aircraft-based Honeywell system.  The distributed Honeywell system has
the advantage of not depending upon the ground-based computer and
communication with it.

The present system includes distributed jammers, one on board every aircraft.
Scot E. Wilcoxon   Minn Ed Comp Corp  {quest,dayton,meccts}!mecc!sewilco
(612)481-3507           sewilco@MECC.COM       ihnp4!meccts!mecc!sewilco


Safety-Critical Software in the UK

"Scott E. Preece" <preece%mycroft@GSWD-VMS.ARPA>
Thu, 20 Nov 86 09:27:44 CST
The proposed regulation of safety-critical software in the U.K. is very
interesting.  What kind of status does the committee that wrote it have?
Are these proposals that are likely to turn into law or are they just
suggestions?
     [This report comes from a very highly respected committee.  After 
      some debate, the proposals may very well get turned into law!  PGN]

The notion of responsibility is a central element of the proposal.  That's a
very good thing.  Everyone building systems should be thinking at all times
that they are assuming responsibility for the use of their products.  That
responsibility should extend to anticipating the potential misuses of the
system as well as to failures to perform to spec.

The proposed definitions at the end make it clear that this proposal is
broader than it might first seem.  They apparently propose to classify and,
presumably, certify systems which endanger money as well as lives.

Defining the threat to life is, of course, non-trivial (shades of the 3+
laws of robotics).  Would the administrative system implicated in the
power-shutoff death reported here a few days ago have been considered
life-critical?  Would avionics systems for which non-automated, but less
capable, backups are available?  Is a program doing image enhancement on
satellite pictures used by weather forecasters life-critical?  How about the
operating system it runs on?

scott preece, gould/csd - urbana, uucp: ihnp4!uiucdcs!ccvaxa!preece


Computer-based stock trading [Some repetition, some new things]

<rutgers!meccts!ems!adam@seismo.CSS.GOV>
Thu, 20 Nov 86 15:58:04 EST
               December 1986 DISCOVER, v7 #12 p13:

                   "SCIENCE BEHIND THE NEWS"
            "DID COMPUTERS MAKE STOCK PRICES PLUMMET?"

News item:  On Thursday, Sept. 11, 1986, the Dow Jones industrial average
dropped 86.61 points, to 1792.89 -- a 4.61 per cent plunge.  A record 237.6
million shares changed hands.  The next day 240.5 million shares were traded,
and the Dow fell 34.17 more points.  Though the decline on Black Thursday
paled next to that of Black Friday, Oct. 28, 1929, when the Dow fell 38.33
points, or a whopping 12.82 pre cent, Wall Street was shaken, and it's still
looking for the cause.  The Securities Exchange Commission (SEC) is
now investigating the possibility that computerized program trading may
have been a contributing factor.
    The decline actually began on Wednesday, Sept. 10, the day before
the big drop.  The bond market in London looked weak, which suggested that
interest rates would remain high, and there were signs of impending
inflation. As always, these indications of a slumping economy drove the
price of stocks down.
    But many analysts believe that the drop was accelerated (though not
initiated) by computer-assisted arbitrage.  Arbitrageurs capitalize on
what's known as the spread: a short-term difference between the price of
stock futures, which are contracts to buy stocks at a set time and price,
and that of the underlying stocks.  The arbitrageurs' computers constantly
monitor the spread and let them know when it's large enough so that they can
transfer their holdings from stocks to stock futures or vice-versa, and make
a profit that more than covers the cost of the transaction.
    The computer programs used by arbitrageurs are based on simple
mathematical formulas that take into account the prices of stocks and
futures, dividends, and interest rates.  "It doesn't require you to have 20
megabytes," says John Barbanel, director of futures trading at Gruntal and
Co. in New York.  In fact, the math can be done on the back of an envelope.
But by the time a trader could do the calculations for his entire portfolio,
the market opportunity would've passed, the price of futures and stocks
changed.  With computers, arbitrageurs are constantly aware of where a
profit can be made.
    However, throngs of arbitrageurs working with the latest information
can set up perturbations in the market.  Because arbitrageurs are all
"massaging" the same basic information, a profitable spread is likely to
show up on many of their computers at once. And since arbitrageurs take
advantage of small spreads, they must deal in great volume to make it worth
their while.  All this adds up to a lot of trading in a little time, which
can markedly alter the price of a stock.  If, say, the arbitrageurs see that
the price of a future has dropped below the price of its underlying stock,
they may buy futures and sell the stock, en masse.  Although Barbanel
emphasizes that arbitrage stabilizes the market over a period of weeks and
months, it can cause a lot of volatility within a single day.
    "Some trader on the floor of the New York Stock Exchange sees all
the arbitrageurs selling at once and bringing down the value of stocks," so
he sells too, says Hayne Leland, the director of Leland O'Brien Rubinstein
Associates, a Los Angeles investment management firm.  Heavy selling leads
to more heavy selling -- and even lower stock prices.  And the fast
calculations of computers can only magnify these effects.  Barbanel says
that 20 per cent of the 86-point drop on Thursday may have come from
computer-assisted arbitrage.

    [A different item included in the same message noted that Standard&Poor
     now reports the S&P 500 index and S&P 100 composite stock price index
     every fifteen seconds instead of once each minute.  (For those people who
     really like to think they are inside the action?  In case you want to
     make your computer-program-based trading "more precise"?)  PGN]


FAA's Role in Developing a Mid-Air Collision-Avoidance System

Chuck Youman <m14817@mitre.ARPA>
Thu, 20 Nov 86 16:01:28 -0500
There have been a couple of items in RISKS lately about mid-air
collision-avoidance systems.  The FAA's role in developing a mid-air
collision-avoidance system was the subject of testimony presented at a
Congressional hearing in September by a GAO official, Herbert R. McLure.  A
copy of his statement can be ordered from the GAO.  The accession number is
131086.  See RISKS 3-67 for their address.  Some of the points Mr. McLure
made in his testimony:

  Controversy still surrounds FAA's 1976 decision to pursue its own system
  rather than fund one that was being developed commercially.  This
  controversy remains largely because the technical problems associated with
  developing FAA's system have proved to be much more complex and
  time-consuming than originally anticipated.  Our work has shown, however,
  that FAA's decision was supported by the aviation community and that, while
  a number of technical problems have delayed the commercial availability of
  FAA's system, these problems have apparently been solved.  Significant
  issues must still be addressed, however, during the testing and
  certification process before FAA's system is ready for commercial use.

  By the 1970's private industry was developing several different systems.
  After testing three, FAA decided that the Honeywell AVOIDS was the most
  promising, but even it had shortcomings.  While the technical problems
  found with AVOIDS were correctable, the most serious shortcoming in all
  three systems FAA tested was that converging aircraft would only be warned
  of each other's proximity if they were both equipped with the system.  
  Since no aircraft had AVOIDS, FAA surmised that a federal mandate would
  have been required to ensure that the system was installed in enough
  aircraft to provide an adequate level of protection.

  Conversely, commercial aircraft equipped with FAA's system, then called
  the Beacon Collision Avoidance System, or BCAS, would be warned of the
  proximity of all other aircraft having a transponder and would receive
  recommended collision-avoidance maneuvers if the other aircraft had an
  altitude encoder.  Since over 100,000 aircraft, or about 65 percent of the
  air fleet, already had transponders, [. . .] FAA believed that its system
  would offer more immediate protection at less cost to the avaition 
  community and that an adequate level of protection could be obtained
  without mandating the system's purchase by all aircraft owners.  Polls
  of aircraft owner and user groups in 1976 and 1979 showed that FAA's
  decision held substantial aviation community support.

  Honeywell stopped development of its AVOIDS system soon after FAA decided
  to proceed with BCAS.  In the intervening 10 years, FAA has encountered
  a number of technical problems that have slowed the development of its
  system, now called TCAS.  In June 1981, FAA's Administrator announced that
  TCAS would be the national standard for mid-air collision avoidance, and
  that the system would be operational nationwide by mid-1985 at the latest.
  While this announcement was overly optimistic, it now appears that the
  known technical problems with the system have been solved.  Testing the
  system in an operational environment and certification are all that remain
  before at least one model of TCAS can be commercially produced.

  FAA's involvement in TCAS research and development has been unusual in that
  it has been conducted in-house by FAA's TCAS program engineering group
  instead of by private industry.  Through its Office of Airworthiness,
  certification of TCAS' effectiveness is also FAA's responsibility.

  Some TCAS program officials felt that FAA's involvement in research and
  development has resulted in over-cautiousness by the Office of 
  Airworthiness in the certification process, and that TCAS is being 
  subjected to much more scrutiny than it otherwise would have been.

  Another kind of problem involves product liability.  FAA officials told
  us they are concerned that if a mid-air collision should occur because
  pilots follow a faulty TCAS resolution advisory, FAA may have to accept
  responsibility and liability for the collision.  They also think the
  issue of product liability would have been a major concern for private
  industry if it had developed the system.

A more complete report is also available from GAO:  "Air Safety:  Federal
Aviation Administration's Role in Developing Mid-Air Collision Avoidance
Back-Up Systems," GAO/RCED-86-105FS, Accession number 129832, April 22, 1986.

A number of the comments I have seen seem to imply that it would still be
possible to implement the Honeywell system.  Since its development was stopped
10 years ago, I doubt it.  Also, I don't think it is valid to criticize a 
decision because in retrospect in may not have been the "best" decision.
I think the criteria should be whether the decision was reasonable based on
the information that was available at the time the decision was made.
Both alternatives were viewed as being technically feasible (and this appears
to be correct even in retrospect).  

An issue that I think we should be discussing in RISKS is whether it is 
appropriate for the same organization to develop and approve critical
systems.  I think some degree of organizational independence is an absolute
requirement.

Charles Youman (youman@mitre.arpa)

Please report problems with the web pages to the maintainer

Top