The RISKS Digest
Volume 3 Issue 54

Monday, 15th September 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

Ada Inherently Secure?
Mike McLaughlin
A million lines of code works the first time?
Ken Calvert
Computers and Ethics
Mark S. Day
New book: HUMAN RELIABILITY: With Human Factors
Elizabeth ?
Answers to WWMCCS Intercomputer Network questions
Harold E. Russell
Info on RISKS (comp.risks)

Ada Inherently Secure?

Mike McLaughlin <mikemcl@nrl-csr>
Fri, 12 Sep 86 09:14:09 edt
The 8 September 1986 issue of InformationWEEK carried an article "Ada Goes
to Work."  A box in that article is "Ada is Finding More Job Opportunities
With European Telecommunications and Banking Corporations" by Philip Hunter.
The following excerpts are from the box.  Deletions... (bridges) [comment]:

"... The Finnish bank Kansallis Osake Pankki has standardized on Ada for 
some... systems, having decided that the language is much better than 
Cobol for developing secure fail-safe applications, with sound structure 
and strong management control."

"... Barclays privately admits that Ada could be the logical successor to 
Cobol for financial systems where security and fail-safe operation are 
essential, ..."

"... its chief appeal to banks is the rigorous structure... This prevents
individual(s)... from making changes that affect other parts of the system. 
The ... application is then to a large extent shielded both from careless 
coding... and from deliberate tampering-including the insertion of logic
time [sic] bombs... "

"... Ada... helps project managers construct secure reliable systems." 

[several paragraphs omitted]

"... British Petroleum and Shell... are evaluating its use for telemetry,
... The... Schlumberger group has... standardize(d) on Ada for oil-field
simulation systems, ..."

"Corporations here in the (U.S.) also are taking up Ada for simulation 
applications, but Europe is way ahead in use (of Ada) for telecommuni-
cations, ..." 

"(other uses include)... Computer Integrated Manufacturing, where a uni-
versal applications-programming environment is needed ... to drive a 
variety of devices, such as robots, machine tools, and vision systems. "

[I have left out several concluding paragraphs.  The thrust of the article
(Ada doing fine in Europe) is skewed by my selection of matters relating
to safety, security, and reliability.] 

    - Mike McLaughlin  <mikemcl@nrl-csr.arpa>


A million lines of code works the first time?

Ken Calvert <calvert@sally.utexas.edu.UTEXAS.EDU>
Fri, 12 Sep 86 11:52:37 cdt


Heard on NPR's "All Things Considered" yesterday evening:
An Air Force Lt. Col., speaking about a kinetic energy weapons
test earlier this week, which apparently went better than expected
in several respects.  If this isn't an exact quote (I heard it
twice, but didn't write it down at the time), it's real close:
"We wrote about a million lines of new computer code, and tested
them all for the first time, and they all worked perfectly."

"Interesting if true - and interesting anyway." - Mark Twain.

Ken Calvert
Univ. of Texas Computer Sciences


Computers and Ethics

Mark S. Day <MDAY@XX.LCS.MIT.EDU>
Thu 11 Sep 86 09:48:37-EDT
In a recent issue of Risks, a contributor suggested the possibility of
substituting the UPC code for walnuts on a package of pecans, to "save
some money".  While I am fairly sure that person was joking, it does
point out an interesting phenomenon in the area of computer-related
risks.  That is, as soon as a computer is involved, people seem more
willing to commit acts of fraud, theft, and espionage than they would
in the absence of a computer.  Thus, people will talk about switching
UPC price tags who would view switching non-computerized price tags as
fraud.  Similarly, people will read mail and data files stored on a
timesharing system, even though it's unacceptable to rifle through
people's desks.

I don't believe that this is due to inadequate security measures on computers.
My desk is unlocked, but that hardly constitutes license for people to paw
through it, even in my absence.  Two possible explanations that occur to me
are 

1) Novelty — computers are sufficiently new that they haven't been included
              in people's "social conditioning".  All of the little stories
              that tell children not to steal, not to lie, etc. don't seem
              to apply to computers and bits.

2) Distance — computers serve as intermediaries distancing the perpetrator
               from the victim.  It is easier to consider and carry out 
               unethical actions when they appear to be carried out on a 
               machine rather than a person.

What, if anything, can/should be done about this problem?

--Mark


New book: HUMAN RELIABILITY: With Human Factors

<ELIZABETH%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Wed, 10 Sep 1986 13:47 EDT
A blurb from Pergamon Press came in the mail today; I thought RISKS
readers might be interested in this book.

Title: _HUMAN_RELIABILITY:_With_Human_Factors_
Author: Balbir S. Dhillon, Mechanical Engineering/University of Ottawa
Other: 1986; 272 pp.; softcover 24.50, harcover 43.50

Blurb: "This first-of-its-kind text explains the important role people
play in the overall reliability of engineering systems, since various
systems are interconnected by human links.  Detailed coverage of these
systems and links are given through data collection and analysis,
development of reliability prediction methods and techniques, and
numerous ready-to-use formulas and mathematical models for predicting
human reliability in a variety of situations.  The introductory
material eliminates the need for prior knowledge of mathematics and
reliability.  Exercises and references follow each chapter.

"Designed for upper-level undergraduate and graduate students, this
text will find application across many disciplines since human error
is a common problem..."


AAAI-86 Report, RISKS 3.41

Harold E. Russell <russell@mitre.ARPA>
Thu, 11 Sep 86 14:25:48 -0500
The report from AAAI-86 (RISKS 3.41, Alan Wexelblat, wex@mcc.arpa) 
had two questions (Q7 & Q8) relating to the WWMCCS Intercomputer
Network (WIN).

The WIN, which is the communications component of WWMCCS, has
received a great deal of bad press dating from the period 1977-79.
Some of it may be pertinent to RISKS FORUM.

RISK:  Using obsolete data for system evaluation.

The most vociferous complaints about WIN date from the period 1977-79
which was a transition phase from prototype (PWIN) to operational 
status.  Use of data from that period may be of academic interest but
it is not relevant to the present WIN which has current technology
hardware and vastly improved software.  I visited several WWMCCS sites
after the transition and found satisfied users who were doing things
that they considered impractical a few years before.  In some cases, 
the WIN was outperforming every other communications medium to the 
point of operating where the parallel communication channels failed 
or were hopelessly saturated.  WIN is now handling more data and 
serving more users than was originally anticipated.  There are still
people whose contempt for WIN is based on data from the transition
era. 

RISK:  Premature transition from prototype to operational status.

Transitioning from a prototype to production or operational status is
always a calculated risk.  This was no different in the case of the WIN.
Go ahead was given based IN PART on the following:

1.  There were still minor but correctable technical flaws in the WIN.
2.  Even in its imperfect state, the WIN provided capabilities which
were not otherwise available.
3.  A situation existed where no applications software was being 
developed for WIN because WIN was not yet available for development of 
applications software.
4.  There would be a learning curve for the applications development
people where the remaining WIN technical problems could be resolved 
before the learning curve started to rise significantly.
5.  There was no way of economically or effectively modeling or
testing the full-blown military network.
6.  Certain categories of highly sensitive military messages would be
prohibited in the WIN.  No reliance would be placed on an unproven
system.

In the case of the WIN, the gamble paid off handsomely, but there are
still numerous criticisms from people who could not or would not
understand the situation that existed in the late 1970s.

RISK:  Adaptation of technology from a different environment.

The WIN was directly derived from the purportedly highly successful
ARPANET which dated back to the late 1960s.  The ARPANET of that era was
essentially a heterogeneous network linking universities and government
research houses.  There were however flaws in the network architecture
and implementation that were unknown, unrecognized or otherwise not 
recorded, which came to light in the homogeneous military environment.  
No one much knew or cared if the University of West Academia unexpectedly 
dropped out of the network because of failures in home-grown software 
or hardware.  In the WIN, a lot of people will take notice if the 
Pentagon suddenly drops out of the network.  Much of the development
effort and many of the problems reported in the 1977-79 period were
associated with correcting deficiencies in the ARPANET architecture and
implementation.  The ARPANET was and still is a very good research 
network where problems are analyzed and corrected on a time-, money-, 
and talent-available basis.  There may be serious problems in the
wholesale transfer of laboratory technology to other environments 
especially critical large-scale military installations.

RISK:  Becoming a victim of one's own success.

At well-managed and well-run sites the WWMCCS/WIN provides good service
and reliability to those who understand its capabilities and limitations.
This results in a good reputation which causes the demands for service
extension to new users beyond those originally intended or causes
existing users to increase their utilization of the system.  Failure to
accommodate these demands yields criticisms of poor response and
inadequate support.  In order to support more users or increased 
utilization, the site equipment would probably require additional 
hardware which is difficult to formally justify and fund.  At the 
present time a typical WWMCCS site has less than half the equipment 
that the vendor defines as a maximum hardware configuration.  If more 
users are granted access than the equipment can support, then
performance can be expected to degrade and complaints to increase.
The WIN provides solid, reliable, effective communications among the 
WWMCCS sites for file transfer, teleconferencing, remote terminal access, 
and mail, but it has throughput limitations.  Performance tests, which 
I conducted two years ago, showed that minimal WWMCCS ADP computers are 
capable of driving the communications lines at near theoretical capacity.
Some people understand why their M16 rifle can't shoot 10 miles but will 
not be convinced that it takes a while to transfer a megabyte file over 
a 56K baud communications link.

WWMCCS ADP and the WIN have a lot of room for technical improvement.  
However, the biggest problems are not technical, but government 
regulations, redtape, funding, and retention of trained, capable 
personnel.  The continual references to statistics and data nearly a 
decade old is misleading and masks current problems and issues.

As always, these opinions may not reflect those of my employers,
associates, or customers, past or present.

Please report problems with the web pages to the maintainer

x
Top