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 12 Issue 11

Tuesday 30 July 1991

Contents

o DEFSTAN 00/55-56
Victoria Stavridou and Andres Ravn
o Computer problems at BCCI
David Shepherd
o Census data in the Land of Oz
Michael Panosh
o Soft Eng Cntrl aids during Hydraulic Failure (Science News)
Jeffrey Sorensen
o Risks of human error in Soviet nuclear "industry"
Ken Mayer
o Cardphone Problems in Ireland
D.P.O'Donoghue
o Book review: Practical Unix Security
Clifford Stoll
o *WRONG* ftp-adress in Brunnstein: Index of Known Malware
Eibo Thieme
o Re: Smart cockpit with no backup
Henry Spencer
o Re: The limits of simulation
Henry Spencer
o Re: Licensing of Software Engineers
Henry Spencer
o Data entry is NOT software engineering..
Thomas P. Blinn
o New Jersey "software engineering" registration legislation
Arthur Rubin
A. Padgett Peterson
Christopher R Riley
Chris Riley
Joseph Beckenbach
o Flawed assertion in RISKS-12.08
Mark Seecof
o Re: Risks of Posting to RISKS
Jerry Hollombe
o Info on RISKS (comp.risks)

DEFSTAN 00/55-56

<Victoria.Stavridou@prg.oxford.ac.uk>
Tue, 30 Jul 91 13:11:43 BST
A COMMENT ON THE REVISED UK MOD STANDARDS 00-55/56
Victoria Stavridou (RHBNC, Univ of London) and
Anders Ravn (DTH, Technical Univ of Denmark)

Our overall impression is that both interim standards have been substantially
improved as a result of the public review exercise undertaken last year. This
is particularly true of 00-55 which has been transformed from a long, confused
and heavily prescriptive document to a much more sensible 2-part volume which
describes the desired goals (Part 1/1 -- Requirements), suggests techniques for
achieving these goals and identifies problems associated with certain practices
(Part 2/1 -- Guidance).

We have found that the formal methods content has been fully retained in this
2nd version and has in fact been improved since its interactions with non
formal design and development aspects have, in many cases, been identified. For
instance, the roles of the formal specification and the English commentary have
been properly assigned (1/1 29.1) and appropriate uses are suggested (the
requirement for verifying the English commentary has been removed!).

Furthermore, this second version of the standard is far less prescriptive.
Instead it identifies the goal and then leaves the designer/programmer free to
use whatever techniques he wants so long as an overall requirement is
satisfied. For instance, instead of banning dynamic memory allocation, there is
now a requirement that the storage bounds during normal operation must be
analysed and peak memory utilisation should not exceed 50% (2/1 30.50.2). The
effect of these changes is that now ProCoS programs (which is of particular
interest to us) would comply with the standard which was not the case for the
previous version of 00-55.

We are, however, less happy with the very weak links between 00-55 and 00-56.
1/1 8.2 on safety integrity analysis requires that this is carried out in
accordance with 00-56; there is, however, no explicit way of relating the
state/event spaces of the hazard analysis stage with that of the specification
and/or program. This is a giant leap which assumes perfect physical components
such as unfailing actuators and sensors! Current work between RHBNC and DTH is
investigating this issue for the ProCoS $SL_0$ and fault tree analysis using
a gas boiler as the running example.

As a minor point, 00-56 states (6.8.1 Table 9) that the probability of human
failure to act correctly in reasonable time after the onset of a high stress
condition is between 0.3 and 1.0. It seems to us that a probability of 1.0 is
pretty probable as in this case one knows exactly what the human is going to
do! You just take the negation!


Computer problems at BCCI

David Shepherd <des@inmos.com>
Mon, 29 Jul 91 11:20:42 BST
Recent UK newspaper reports have commented that the receivers who are trying to
sort out the fraud at the now closed Bank of Credit and Commerce International
(BCCI) are being greatly hindered by the fact that all the data is stored on an
"archaic" computer system. They are also concerned that someone tipped BCCI off
about the investiagtion before the bank was closed and that the computer
records have been deliberately confused.

david shepherd: des@inmos.co.uk or des@inmos.com    tel: 0454-616616 x 379
                inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq

    [A strong suspicion is that the records had been deliberately confused
    all along.  PGN]


Census data in the Land of Oz

Michael.Panosh, Unix.Education, Australia <MWP.MICHAEL@melpn1.prime.com>
Tue, 30 Jul 1991 12:49:36 +1000
Australia is coming up to another census exercise.  Overheard on a
breakfast radio news broadcast (paraphrase):

  "Confidentiality of data is assured as all the census papers are shredded."

Reassured me no end!!

Michael Panosh, Prime Computer, Australia -- mwp.michael@melpn1.prime.com


Science News Article: Soft Eng Cntrl aids during Hydraulic Failure

Jeffrey Sorensen <sorensen@spl.ecse.rpi.edu>
Mon, 29 Jul 91 12:20:05 EDT
   [Jeffrey drew PGN's attention to a Science News article, 27 July 1991 (V
   140, N 4, p 63), entitled "Software may ensure safer landings".  It
   discusses recent problems with hydraulics (including the 1989 Iowa failure),
   and discusses a new software system:]

The new software system has been tested on various flight simulators,
including ones for the McDonnell Douglas F-15 and the Boeing 720.  These
simulators showed that with only manual control of the engines, crews could
maneuver their planes but would have great difficulty landing.  With
software-controlled engines, however, pilots repeated simulated safe landings
-- even in turbulence and crosswinds.

[For the full article, contact Science Service, Inc., Editorial and Business
Offices, 1719 N St. N.W., Washington DC 20036 (202-785-2255)]


Risks of human error in Soviet nuclear "industry" (Blinn, RISKS-12.08)

Ken Mayer <ken@visix.com>
Mon, 29 Jul 91 17:27:44 -0400
Whenever I see the words "human error" I always think "human interface design
error." I bristle at the idea of blaming people instead of poor design because
the operators are the ones who are least able to defend themselves. The most
highly skilled, trained human being will still make mistakes every now and
then. It is up to designers to build systems that tolerate mistakes, and
provide an unambiguous path to a solution.


Cardphone Problems in Ireland

"Parsifal aka D.P.O'Donoghue" <8614903@ul.ie>
Mon, 29 Jul 1991 14:20 GMT
The recent thread about disturbances in phone software brought to mind the
disruption earlier on in the year to the Cardphones installed by Telecom
E/ireann (Irish State phone co) around this campus.

For some reason -never explained or publicised- for a period of approx 2 weeks
users could utilise the Cardphones on Campus free of charge. Somehow someone
discovered that by dialing the free number "17" (used to test ringback etc),
hanging up and then lifting the receiver when the ringback occurred a dialtone
was available. This news spread like wildfire amongst the non-Irish students
here who took the opportunity to ring home. A certain amount of discreet
observation meant that other people found out the method and rang for nothing.

About two weeks later all the cardphones were out of order with a notice
stating that a "network upgrade" was taking place and that was the end of that.

Desmond P.O'Donoghue   8614903@ul.ie


Book review: Practical Unix Security

Clifford Stoll <well!cliff@fernwood.UUCP>
Wed, 24 Jul 91 14:11:43 pdt
Practical Unix Security, by Simson Garfinkel & Gene Spafford
O'Reilly & Associates, Inc. ISBN 0-937175-72-2

Now, here's a book that's long overdue.  If you're managing a Unix system, get
this book.  You'll learn much more than just how to secure your system.  Garf
and Spaf walk you through networks, file systems, and Unix internals, a tour
customized for finding security weakness.

Previous Unix security books were aimed at stand alone systems; this is the
first that discusses Unix security in a networked environment.  It's a
practical book ("Never use

Set-User-Id-Shell Scripts") with an underlying current of "here's how Unix
works -- be careful of this wrinkle".

Plenty of good stuff here: A chapter on how to discover a break-in, another on
legal issues and privacy.  A list of sensitive files in Unix.  How to figure
out Unix log files.  Security implications of X-windows and NFS.  Kerberos and
Secure RPC.  Most important, this is the first book to show you how to secure
your computer in a networked environment.

Today, most Unix computers have no system administrator.  For others, a single
manager handles for dozens of workstations.  Old time security -- strict
isolation -- just won't work.  Instead, security depends on understanding
acceptable network interactions.  For a harried system manager, this book will
pay for itself in aspirin.

A few omissions: secure id cards, intrusion detection expert systems, and the
Andrew File System.  A few chapters are wasted on obvious things: backup your
data, change your passwords, RS/232 pinouts, and the old shopworn arguments
about what a hacker is.

It's sad that this book needs 500 pages.  Their security checklist is twelve
pages long -- nobody will ever go through the entire list.  Is this the fault
of the authors?  Or of Unix?  Hard to say, but I sure wish there were an faster
path to a tight system.

-reviewed by Cliff Stoll  22 July 1991


*WRONG* ftp-adress in Brunnstein: Index of Known Malware (RISKS-12.08)

Eibo Thieme <eibo@rosun1.informatik.uni-hamburg.de>
Mon, 29 Jul 91 16:51:00 +0200
The adress of our ftp-server contained a small error, here is the correct
version. But remember that our line is really slow !

VTC documents (Index of Known Malicious Software: IMSDOS.791; Index of Virus
Catalog: Index.791; all entries classified up to now) are now available from
FTP:
         Our FTP server:  ftp.informatik.uni-hamburg.de
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         Login anonymous
         ID as you wish (preferably your name)
         dir: directory of available information
         cd pub/virus: VTCs documents


Re: Smart cockpit with no backup

<henry@zoo.toronto.edu>
Tue, 30 Jul 91 12:54:16 EDT
>...  In the event of a computer failure, the only good that mechanical backup
>instruments would do would be to let the pilot watch the altitude ticking off...

There is some justice in this; "if the computer fails, you're dead".  But...
"The" computer?  *Which* computer?  "Fails"?  Fails *how*?  It is not at all
inconceivable to have a failure in which some control remains but sophisticated
instrument presentations are scrambled or absent.  Indeed, one would hope that
the last-ditch emergency fallback mode of the software would be to provide
basic control and nothing more.
                                         Henry Spencer at U of Toronto Zoology


Re: The limits of simulation

<henry@zoo.toronto.edu>
Sun, 28 Jul 91 19:58:59 EDT
>  simulations of the [motor's] firing dynamics did not reveal subtle factors

Actually, this may not quite be true, it turns out.  I'm told, by folks I
shouldn't identify, that some of the simulation work *did* at least hint at
problems.  This was not followed up, possibly as a deliberate decision by
managers who didn't want to hear bad news.
                                                 Henry Spencer


Licensing of Software Engineers

<henry@zoo.toronto.edu>
Tue, 30 Jul 91 13:06:41 EDT
>It only requires licensing of those who offer themselves for hire as software
>ENGINEERS.  Hire and engineer are both key words...

An excellent point.  Many of the readers of this list may not be aware that
it is *already* illegal to offer yourself for hire as, say, a "mechanical
engineer" without being a licensed professional engineer.  The NJ law is
closing a loophole in existing practice, not introducing something new and
radical.  "Engineer" is the crucial word; that term is legally protected
and cannot be used frivolously... in any other field.

(One exception to this: if you are working for somebody else, *they* can call
you an "engineer" without requiring such qualification.  [There may be some
slight restrictions on this, I'm not up on details.]  The more activist
engineers have been known to agitate for removal of this rather large
exemption.)

Far too many people call themselves "software engineers", many of them having
nowhere near the background and demonstrated competence expected of a licensed
engineer in more traditional fields.  While implementing the NJ law is going to
be, um, a learning experience for all concerned, it's a step in the right
direction.
                                         Henry Spencer at U of Toronto Zoology


Data entry is NOT software engineering.

"Dr. Tom @MKO, CMG S/W Mktg" <blinn@dr.enet.dec.com>
Tue, 30 Jul 91 09:04:08 PDT
In RISKS 12.10, Bill Murray and Bob Frankston comment on the NJ legislation
requiring the registration of "software engineers".

On the whole, I agree with Bill Murray.  In spite of the fact that I program,
and have even done a certain amount of "software engineering", I doubt that I
could qualify as a "registered professional software engineer", in spite of my
formal education (at the doctoral level) in computer and computing science and
applied statistics.

I find it amusing that Bob Frankston asks "What about a VCR programmer?"  The
stories of unusable human interfaces in commercial VCRs abound, but I'd hardly
characterize the "data entry" aspect of most home VCR use as "programming".
In fact, if "VCR programmers" were really software engineers, they probably
would have learned (at least a modicum) of human factors considerations, and
the products extant in the marketplace might be more approachable.

Bob assumes the legislature is attempting "to codify what is not understood."
Actually, the registration and certification of professional engineers is well
understood, and it is the very lack of such that evidences the non-professional
status of our business.

Dr. Thomas P. Blinn, Digital Equipment Corporation, Digital Drive -- MKO2-2/F10
Merrimack, New Hampshire 03054  ...!decwrl!dr.enet.dec.com!blinn (603) 884-4865


New Jersey "software engineering" registration legislation

<a_rubin@dsg4.dse.beckman.com>
Mon, 29 Jul 91 13:18:49 PDT
.... and risks of not looking at your posting software.  The original file uses backspace
characters to simulate underlining.  Most of the underlined text was
"design/designing" replacing "engineer/engineering".

2165888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal)
a_rubin@dsg4.dse.beckman.com (work)


Software Engineering Registration (NJ)

A. Padgett Peterson <padgett%tccslr.dnet@uvs1.orl.mmc.com>
Mon, 29 Jul 91 17:06:29 -0400
    The concept of registration for "software engineering" seems novel in
that the proposal seems to both go too far and not far enough (thanks Bill).
The concept that all programming be regulated, even all commercial programming,
is ludicrous. At the same time certain catagories of programming cry out for
regulation.

    As a licensed Professional Engineer, my primary responsibility is to
ensure that certain engineering tasks are done in accordance with regulation
and in a safe manner. The state of Florida has decided that I (as a result of
experience and testing) am competant to determine this. One of the
not-so-evident responsibilities is to not accept work that I am not qualified
to perform.

    In the past, I have had the opportunity to work on many projects that
did not require licensing including digital flight controls for several
aircraft and a communications topology for the FAA National AirSpace Plan, two
areas that probably should have been covered by such licensing.

    Other areas that come to mind are many medical software elements,
computer assets used for road and traffic control, and emergency
telecommunications networks. Certainly, IMHO in recent months we have seen
several examples of what happens when software is developed without evident
control.

    That complex software is difficult to debug does not seem to be an
adequate defense for mistakes yet as more and more software replaces mechanical
processes, the potential for danger increases. Certainly the computer in my
wife's car is easily overridden since mechanical linkages from the wheel to the
steering and from the accelerator to the throttle plate still can override any
electrical command. A computerized highway control system is another matter.
Consider the implications if a traffic signal were to display green in all
directions simultaneously. (Yellow might be worse).

    Consequently, as more sophisticated systems come into use, a formal
method needs to be established to determine that adequate safeguards are
provided. The problem is that often, only the designer or design team has the
expert knowlege of a particular system required to determine its safety.

    This is the reason that registration of engineers came about in the
first place: since every critical design cannot be validated, we have to
validate the designer. It is not the perfect answer, merely the best choice
from what we have.

    The major problem that comes about is in designing a certification
process that achieves its goals, not an easy task in any discipline but even
more so in software since it is still evolving. In electrical engineering, the
processes involved in providing adequate power for a building are well defined
and codes have been developed that set out these rules. Nothing similar exists
for software.

    To make matters more difficult, while electrical quanta are reasonably
well defined (Alternating Current usually means either 60 or 400 hertz for most
purposes & leads and lags are well defined), good computer software must
consider the platform, clock speed, memory speed, bus speed, race conditions,
failure conditions and a host of other variables, something many programmers
are insulated from.

    Consequently, at some point, critial designs must be examined by
someone who understands not merely the software, but the compiler, the
operating system, the CPU, and the installation as well. I would not feel very
safe near a nuclear power facility using a control program designed in Visual
BASIC by someone who only understood Windows (trademarks acknowleged) though
the approach might be well suited to balancing my checkbook.

    I can see a very valid need for a counterpart in software to the same
certifications a licensed engineer makes when signing off on an engineering
design: (in English)

1) I am competent to decide if this design is safe and meets applicable design
   standards.

2) I have examined this design in sufficient detail to make this determination.

3) Based on study and in my professional opinion this design is safe &
   meets all applicable standards.

4) By affixing my seal, I personnaly certify that this design and my study
   of it meet the above criteria.

    While the general public is often only aware of (3), all elements are
actually present and failure of any element is grounds for censure/suspension
/revocation of a professional license - in fact most of the board actions that
I see result from defects in (1) or (2).

    It should also be mentioned that in many organizations, often only the
Chief Engineer needs to be licensed. I would suspect that a Software
Engineering license would be much the same.

    In short, I can see a very real need for such a licensing requirement,
not globally but for those engaged in approval of critical or safety-related
projects. The major problem will come from the certification process itself
given the bewildering array of platforms, embedded micro-controllers, and
languages. It will not be trivial to impliment but is something that needs to
be done.
                    A. Padgett Peterson, P.E.


Re: Licensing of Software Engineers

Christopher R Riley <chris@mtuxo.att.com>
Tue, 30 Jul 91 11:52:52 EDT
I think there is a misunderstanding of who is to be licensed.  I have seen
copies of the text that says "software  1[engineer] ________1" and
another that says "software  1[engineer] designer1".  The footnote at the
bottom of page 1 of my copy says:

    EXPLANATION--Matter enclosed in bold-faced brackets [thus] in the
    above bill is not enacted and is inteded to be omitted in the law.

    Matter underlined thus is new matter. Matter enclosed in
    superscript numberals has been adopted as follows:
    1 Assembly ACP committee amendments adopted June 13, 1991.
    2 Assembly floor amendments adopted June 24, 1991.

Some people's text does not have the word designers, but just the
underlining (probably from backspace-underscore pairs in the text).

I think the bill is intended to license software designers.  My question is,
does this mean that all people who write any piece of software code is a
software designer, and thus must be licensed?

Chris Riley   chris@mtuxo.att.com


Re: New Jersey "software engineering" registration legislation (J.M.Ritter)

Joseph Beckenbach {Adapter Software Release Engr} <jerbil@ultra.com>
Mon, 29 Jul 91 18:48:09 PDT
        The two most relevant points here:

1)  How does this Act differ from any other Engineering Licensure within NJ?

        Answer:  I don't know, but someone with a reasonable lawyer in New
Jersey could probably find out some information for us.  The language seems
loose (regulating all practicing "software engineering"), but then we need
to compare it to other language being used to regulate, eg, civil engineers.

    To my mind, it's a large step in the right direction.  Not everyone
who's wrapped a bandage needs to be a licensed medical practitioner, just
those who intend to make a living of it as a main provider.  At least, that's
a simplification of my understanding of licensure.


2)  How does this affect the "common practitioner"?

        Answer:  Again, I don't know.  However, looking at the parallels with
other professions, I would venture my layman's interpretation:  only those
with proper qualifications may legally use the word "Engineer" to refer to
themselves professionally.
    It does mean that all the job descriptions titled "Software
Engineer" will need to turn into "Member of Software Technical Staff".


    I'll try to look over it a bit more before adding more humble opinion
to the network.   Meanwhile, it needs comparison to other Engineering
Licensure statutes, such as for civil engineers and architects.

        Joseph Beckenbach
        Californian "software-engineer-wannabe"

Test programs not programmers, but license software ENGINEERS!

Joseph Beckenbach   jerbil@ultra.com    408-922-0100 x246


Flawed assertion in RISKS-12.08

Mark Seecof <marks@capnet.latimes.com>
Fri, 26 Jul 91 11:49:15 -0700
I'm catching some (well-deserved) heat about my assertion that it would
"obviously" be impossible for a large majority of drivers to be "(much) better
than average."  This was poorly expressed, especially if "average" means
"arithmetic mean" (of scores in some simple metric).

I should have written out my opinion that an "ability score" versus population
plot would reveal a typical "bell-shaped curve," that most drivers would have
scores near the middle, that few drivers would score very far above the median,
that by definition half of them would score at or below it, and that biases
(thank you, Mr. Tanner <mtanner@gmu.edu>) in drivers' perceptions of other
drivers on the road would factor into their self-assessment of superiority in
such a way as to render it over-optimistic.

    [Messages were received from Tim Smith <ts@cup.portal.com>:

  "1 1 8 8 8 8 9 9 9 9.  Note that the average of these 10 numbers is 7.  Note
  that a large majority of them are above average.  This is obviously possible."

    ... and Jeremy Grodberg <lia!jgro@fernwood.mpk.ca.us>:

  "And when it looks like statistics are *not* being abused, remember that
  97.325% of all statistics are made up."  ]


Re: Risks of Posting to RISKS (Dunlop RISKS-12.06)

The Polymath <hollombe@ttidcb.TTI.COM>
Thu, 18 Jul 91 15:42:44 -0700
There seems to have been an enormous misunderstanding here.  That, or lawyers
have gotten into the works, somewhere.  I hope I can clear things up to
everyone's satisfaction.

}In RISKS 12.02, Jerry Hollombe describes our publication of his 1989 RISKS
}posting about the "censorship" of rec.humor.funny at Stanford University.  Mr.
}Hollombe's piece was reprinted (with his permission) in Charles Dunlop and Rob
}Kling (eds), _Computerization and Controversy: Value Conflicts and Social
}Choices_ (Boston, Academic Press, 1991, ISBN: 0-12-224356-0). (See pp.376-379).

[Further details omitted]

Absolutely true.  I gave my permission.  I had no complaints then and I
have none now.  In fact, I'm quite proud of having been included in the
book and have been calling my friends' attention to it.  Some have
expressed interest in obtaining copies for themselves. (I'm reading
through it as time permits.  So far I've found it interesting and thought
provoking).

}... However, we did not effectively anticipate this new controversy
}about computerization: one's ability to fairly reprint RISKS (or any BBS)
}postings after posters have given explicit permission!

I certainly never intended to raise such an issue.  Even if I did have a
change of heart (which I didn't) I like to think I'm honorable enough to
live with the consequences of my actions.  My word, once given, stands.  I
would not retract it even if I wanted to and could.  You had my permission
to publish.  That stands.

}   Unfortunately, Mr. Hollombe attributes his problem with the reprinting of
}his RISKS posting solely to publishers and editors, and he conveniently ignores
}his control over the publication.  In RISKS 12.02 he writes:
}
} >The risk?  The words we exchange here aren't as ephemeral as they may
} >appear on a VDT screen, so be careful what you say and how you say it.
} >You  never know  who might decide to package and ship it to a customer.
} >(-:
}
}   This complaint strikes us as unfair.  ...

This was not intended as a complaint and I'm amazed, and horrified, to see
it interpreted as one.  As I said in my posting, and have repeated here, I
gave my permission for my words to be published.  I've had no regrets
about that, then or since.  Very much the contrary, in fact.

What I was attempting to convey was the idea that many people read, keep
copies of and even disseminate what's posted here.  It therefore behooves
us to write thoughtfully, at least.  On a more mundane level, I might have
been more reluctant to give permission to use my posting if it had been
full of spelling and grammatical errors.  I was NOT complaining about the
fact of its publication.

}... We believe that ...
}we were VERY FAIR to Mr. Hollombe.

I believe you were more than fair.  I'd say you were outright generous.
I'm not complaining.  Tell your lawyers to relax, if that's the problem.
I'm not going to sue you.  I like being published.  Really.

I don't know what more I can say at this point.  Please feel free to
contact me directly if you have any further questions about the matter.
I'll be happy to reconfirm my permission to publish, in writing if that
will help.

(Alas, it seems the old risk of being misunderstood in written media is alive
and well.  That's no one's fault.  It's just the nature of the situation).

Jerry Hollombe, Citicorp, 3100 Ocean Park Blvd. Santa Monica, CA 90405
{rutgers|pyramid|philabs|psivax}!ttidca!hollombe  (213) 450-9111, x2483

Please report problems with the web pages to the maintainer

Top