The RISKS Digest
Volume 15 Issue 7

Wednesday, 6th October 1993

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…


o ISDN telephone glitch in Hamburg
Klaus Brunnstein
o Japan: IT Security, JCSEC criteria
Klaus Brunnstein
o Re: The FBI investigating college pranks
Fredrick B. Cohen
o Re: Conditioning and human interfaces
Robert Dorsett
o Re: Answers to the mail problem
Fredrick B. Cohen
o Trusted portions
Fredrick B. Cohen
o Think of it as an opportunity, not a problem
A. Padgett Peterson
o Re: Risks of Unverified Driving Records
Robert J Woodhead
Jim Cook
Rex Black
o CFP "Ethics" Workshop Cuba Feb.1994
Klaus Brunnstein
o Info on RISKS (comp.risks)

ISDN telephone glitch in Hamburg

Klaus Brunnstein <>
Fri, 17 Sep 1993 14:07:38 +0200
On September 16, 1993, about 12,000 Hamburg based customers of Germany's new
ISDN digital telephone system were hit by a software bug from which telephone
services could be recovered only after almost 12 hours.  Mainly commercial
users (about 25% of Hamburg's presently 50,000 ISDN customers) were unable
to use their telephone, fax and data services until after noon.

According to a German Telecom official, the problem arose when a new software
was loaded on the ISDN control systems, at 2:00 am.  Probably due to a bug,
systems crashed and subsequently also refused to load the old software.  Only
at 1:15 pm, system engineers succeeded to restart the old system version.

ISDN is the Integrated Services Digital Network, which allows to transmit all
sorts of communication (fax, telex, texts, data, telephone calls) via a
digitized network with one type of connector box.  At this time, out of 1,2
Mio telephone customers, 50,000 have yet ISDN based system, including the
author's faculty, with daily bad experiences about broken calls, false
connections, devices beeping for no rationale reason etc.  Fortunately, the
author's telephone set was operating in the "usual" way during this blackout.

Klaus Brunnstein (Uni-Hamburg, September 17, 1993)

   [By the way, someone PLEASE tell Klaus that his mail addresses --- both
   d400 and dbp --- no longer work from my system!  Something broke.  PGN]

Japan: IT Security, JCSEC criteria

Klaus Brunnstein <>
Thu, 16 Sep 1993 19:54:42 +0200
It is not well recognized in the current discussions in North America and
Europe aimed at harmonizing their different criteria (FC, ITSEC) that Japanese
organisations are undertaking major efforts to assess and improve the state of
IT and Communications security also in their country. In order to guarantee
their IT industries' opportunities in international markets, they are also
looking for a minimum harmonized set of criteria (JCSEC) as a basis of
universally applicable product evaluation and certification.

Among others, Information-technology Promoting Agency (IPA) and Japan
Electronic Industry Development Association (JEIDA) have started their
respective work with major analyses of the state-of-security in Japan, North
America, Europe and Australia. IPA, a MITI funded organisation with interests
in AntiVirus measures, sponsored a study which received some attention in
1992.  Its basic statement was that the number of hacker-like attacks on
systems doubled in recent times while virus infections diminished
significantly. It is interesting that IPA's recent statistics about viral
events in Japan sharply increased in 1993: from 1990's total 14 events over
1991's total 57 events and 1992's 252 events, the partial figures in 1993
(Jan-July) are 366. While findings in Mac (less than 10 reports) and so far 19
viruses having appeared on the (IBM-incompatible) Japanese PCs (15 reports in
1993) are constant, the very fast growth of IBM compatible PCs is based on 42
different viruses, with 166 Yankee Doodle, 103 Cascade 1701/1704, 24
Anti-Telefonica, 20 Stoned III or Michelangelo and 14 Form reports in 1993.
Though IPA's request for reporting virus events is now known in many
enterprises, these figures do NOT indicate the exact number of infections but
only show the relative development: growth.

As its basis for future work, JEIDA has published a "Summary Report on the
Worldwide Survey for Information Systems Security in Nine Nations", conducted
by Coopers & Lybrand, in March 1993. The survey which is based on 1,059
questionnaires filled from enterprises in Japan (39%), Australia (21%), North
America (15%) and Europe (13%) analyses the state of security consciousness
(chapter 1), experience with incidents (ch.2: e.g. malfunction of
hardware>75%, introduction of viruses >30%, theft of equipment about 10%,
disclosure of Passwords: 10%, etc), and IS Security Measures taken (a rather
detailed analysis, ch. 3). An analysis of the Cost of IS Security Measures
(ch. 4) and IS Risk Analysis (ch. 5), Motivating Factors (ch. 6) and
Development Priorities (ch. 7) concludes this study (17 pages). For detailed
analysis, it would be helpful to complement the hi-quality color print with a
volume containing more details of the raw data, but this "JEIDA Study" is
worthwhile to read for worldwide comparison.

JEIDA published another study in August 1992 "Japanese Computer Security
Evaluation Criteria: Functional Requirements (Draft V1.0)" which has not been
recognised so far in the Western discussion (similar to Russia's development,
published in December 1992, though in Russian). JEIDA's study (in English),
developed after MITI guidelines, describes (ch.1: Introduction) Functionality
Requirements, with scope of the "Target of Evaluation" (TOE) and Target
Models, and gives detailed "Functional Requirements" (ch.2), including minimum
requirements for Identification and Authentication (2.1), Access Control
(2.2), Accountability (2.3), Auditing (2.4), Object Reuse (2.5), Integrity
(2.6), Reliability of Service (2.7) and Data Exchange (2.8). Though the
structure conforms with ITSEC concerning the 8 basic function categories,
JCSEC evidently follows US' Minimal System Function Requirements philosophy
which is also basic to ECMA's (European Computer Manufacturers Association)
and ISO/IEC JTC1 SC 27 works. The report (26 pages) ends with a graph
describing the different security criteria in USA, Europe, Japan and ISO,
followed by a glossary with informal definitions of essential terms.

Though the Assurance part of JCSEC has not been published so far (due
end-of-1993), it seems as if ITSEC's Assurance levels may play the role of
related "Minimum Assurance Requirements" (rather than the complex Assurance
descriptions in US' Federal Criteria).

JEIDA officials motivated their work in JCSEC generally with their vendors'
experience when having attempted to sell Japanese IT systems in Australia.
Following regulations for Australian government installations, which seem also
to be applied by major Aussie enterprises, Japanese installations had to
undergo a security evaluation process which was partly difficult as most
documents were not available in English. When being forced to prepare
evaluation and certification of their products in non-Japanese countries, MITI
and Japanese vendors evidently concluded that a set of internationally
harmonized criteria with minimum requirements would serve their interests
best. Moreover, Japanese vendors seem to favour self-evaluation of security
functions, as opposed to an evaluation by independent institutions as
practiced or prepared in USA and Europe. As some of these ideas are shared
also by IT vendors outside Japan (see ECMA's approach), the Japanese
involvement may add fresh wind to the international ITSEC discussion which is
presently dominated by USA/Canada and Europe (including their preoccupations

Klaus Brunnstein (Univ-Hamburg, September 16, 1993)

PS: JEIDA's address is: Japan Electronic Industry Development Association,
JEIDA, Kikai-Shinko-Bldg., 3-5-8 Shiba-Koen, Minato-ku, Tokyo 105 JAPAN.

Re: The FBI investigating college pranks

Fredrick B. Cohen <fc@Jupiter.SAIC.Com>
Wed, 6 Oct 93 05:00:48 PDT
It's a sad state of affairs when the FBI investigates a college prank but
doesn't investigate murder and rape running rampant through the nation.  When
I was in college, students sent a resignation letter from the Dean of Students
to the President on official letterhead.  There was no federal investigation,
and the most any student would ever get for such a prank would be a stern
lecture about being sociable.  If they investigated half the pranks the FBI
would be forever chasing kids around our college campuses.  Lets keep some
perspective on things and spend our federal time and money on something more
useful. - How about a study of how many times a butterfly flaps its wings
before it dies?  FC

Re: Conditioning and human interfaces (Sosman, RISKS-15.06)

Robert Dorsett <>
Wed, 6 Oct 93 19:57:09 CDT
> ... Mr. Dorsett's point (perhaps) should be that there ought to be a
> Standard Standard...  But are today's interfaces so good that we're
> willing to discourage innovation?

There's no innovation in these approaches.  They are all on the same
cognitive level, using similar display and input mechanisms.  They are
merely different permutations of a theme, often guided by no "philosophy,"
just GUI extensions of old-fashioned CLI-style prompts.

So, in this case, yes, there is only one credible type of solution, and,
yes, especially when PC's are trying desperately to turn into Macintoshes,
and when huge segments of society are used to standard keyboard formats,
some standard heuristics should apply, one way or the other.

Robert Dorsett!!rdd

Answers to the mail problem

Fredrick B. Cohen <fc@Jupiter.SAIC.Com>
Wed, 6 Oct 93 10:02:47 PDT
Three answers came up that I thought might be worth sharing:

1 - Some versions of sendmail have a capability to refuse mail after disk
space is reduced to a specified constant.  This resolves the flooding problem
but does not allow legitimate mail to pass.

2 - Some people think you should have a separate disk partition for mail and
News (where this apparently happened regularly to some people by accident),
which solves the problem except of course it denies legitimate mail.

3 - Some systems allow user-based quotas under which mail falls, but in many
systems this doesn't work because the superuser delivers the mail, and thus
the legitimate user is run out of space while the system is also run out of
space.  Some people mentioned that they hadn't tried limiting quotas to all
system user but that it would be necessary to limit the impact of this

Most respondents said that they felt this was a fairly common state of
affairs.  In other words, as delivered, systems don't handle this well, and
most systems administrators don't know how to, aren't aware of, don't have the
time to, or for whatever reason don't do anything about this problem.

I wonder how many things besides mail and news create this possibility.  Does
anyone know of any other information sent to a system that automatically (by
default) consumes disk space?  It would be worthwhile to classify these things
and keep them in a common place so we know that a particular partition has
them all, and know where to look.  P.S. I make one partition per disk to get
rid of the stupidity of having to keep things in different directory
structures just because my computer isn't smart enough to figure it all out.
It only hurts under a few circumstances, and it makes life easier in a lot
more of them.

   We received a large amount of mail on this topic, including that from (Hans van Staveren) (Roger Binns) (mathew)
     wfg! (Michael T Davis) (Tad Taylor) .
   Several suggested that THEIR mailers are not so stupid, and suggested
   various well-known ways of handling the problem.  Thanks.  PGN]

Trusted portions

Fredrick B. Cohen <fc@Jupiter.SAIC.Com>
Wed, 6 Oct 93 10:02:47 PDT
    Trusted portion should be small, but then there is the problem of the
interface between the trusted and untrusted portions of the program.  One way
to deal with this is via a cryptographic interface between authorized and
unauthorized portions of programs.  Another alternative is to have the trusted
program verify the integrity of the untrusted program.  Just a thought. - FC

P.S.  I have had a small trusted program for separating trusted from untrusted
segments of programs for quite some time, and it works well, but it's not all
that easy to use correctly. - FC

Think of it as an opportunity, not a problem (Re: Willey, RISKS-15.06)

A. Padgett Peterson <>
Wed, 6 Oct 93 08:25:04 -0400
[Was: Software Quality vs Staff Size]

"The customer is always right". One approach that was inspired by several
other RISKS entries would be to split the group into 2 or 3 teams and give
each one the same requirements. When each is done feed the same test cases
in and see what the results are. Once they always agree, pick the best/
fastest/most elegant one & deliver.

Once upon a time, "safety of flight" dictated IV&V (independent verification
and validation) of all software. IMHO many of the RISKS postings have
indicated that even simple quality control is a thing of the past.

Two years ago my wife was in an automobile accident that required removal of
the battery from our car. Yesterday I had occasion to disconnect the battery
& discovered that Godzilla must have replaced it, probably with an impact
wrench. The terminals were screwed on so tight that the attachment post
ripped out of the battery before loosening, causing an acid leak (yes, I
was turning it the right way 8*(, and ruining the battery.

Latent software errors are like that, sometimes taking years to show up, and
are caused much the same way — someone operating without supervision and
outside their field of expertise. In my experience with programming, (and that
goes back longer than I would care to admit) very few "programmers" really
understand the systems they are working on — certainly very few people
worldwide understand the BIOS in a PC yet this is what makes a PC "100%

There are over 150,000,000 PCs worldwide now, probably less than
500 people who have any understanding of the BIOS (and half of them write
viruses). Yet what would one expect the architecture for that medical device
mentioned in to be ? Would anyone be surprised if there was an Intel iapx
80x86 based system inside ?

Maybe it is time for certification, at least for devices that are safety

Re: Risks of Unverified Driving Records (Kabay, RISKS 15.06)

Robert J Woodhead <>
Wed, 6 Oct 93 20:52:57 JST
In RISKS-15.06, Mich Kabay writes about the Risks of unverified
driving records, and the problems of an erroneous record leaving
one stranded at the airport sans auto.

There is a simple solution that avoids most of the problems; the
Car rental companies should be allowed to refuse to accept a
reservation, but not cancel one once it has been made.  Thus,
the client would be asked when he phoned for the reservation for
his driver's license number.

This would have the side-effect of giving the driver an early
warning that there is a problem with his record (either a real
problem with his driving, or someone elses typing problem)

Robert J. Woodhead, Biar Games / AnimEigo, Incs.
AnimEigo US Office Email (for general questions):

Re: Risks of Unverified Driving Records (Kabay, RISKS 15.06)

Jim Cook <>
Wed, 6 Oct 93 11:20:38 EDT
In commenting on shared driving records, Michel E. Kabay comments:

  "It will not be good enough to allow just anyone to make ostensible
    corrections in our records, either. Some method of identification and
    authentication will have to be devised to prevent nasty people from
    damaging other people's histories."

I really have to comment on this:

Suppose you suddenly find yourself with a bad record one day.  It only took
one person a few minutes to accidentally or deliberately make this erroneous
error one day.  What level of authorization did that person have?  Frequently,
very little.

Now you want to correct it.  What level of authorization do you need?
Frequently, you probably have to go through heck and high water to do so.  And
consider the time factor: the entry was made in a minute.  The correction
takes weeks.

Think about credit records.  This has all come up before.  And there you often
are not allowed to expunge the record, rather, just add a correction below (if
at all).

I understand Michel's sentiment to prevent wrong-doing.  But from everything I
read, it's the legitimate that have been losing out.

C. James Cook, Epoch Systems, Inc., 8 Technology Drive, Westboro, MA 01581

Re: Risks of Unverified Driving Records (Kabay, RISKS 15.06)

Rex Black <>
Wed, 6 Oct 93 10:09:45 CDT
I think Mich's suggestions are excellent.  Certainly the subject should
have the right to verify information which directly affects his quality
of life.  However, I don't think this will entirely resolve the problem,
because it doesn't cover some crucial economic issues.

Most data collection agencies are for-profit corporations. While they have an
interest in selling reasonably accurate data to their clients, their clients
value the data most from the point of view of _preventing_ a business decision
that results in a major loss.  In the car rental example given, the rental
agency looks for background data that proves "badness".  The risks for both
purchasers of the data and the data subjects arise when the purchaser of the
data is attempting to use the information to exclude a bad-risk subject.
However, note that, while the data purchaser bets a possibly substantial
amount of money that the data will identify bad risks, and the subject bets
substantial inconvenience and possibly money that the data will not
incorrectly finger him/her as a bad risk, the data provider risks virtually
nothing in any transaction.  I say "virtually" because, if the agency fails to
identify bad risks often enough, the data purchaser may choose another data
provider.  However, the agency may misidentify good risks as a bad ones a
number of times without consequence to it, and it is unlikely that the injured
party in this circumstance (the subject) will convince the data purchaser to
dump the data provider on the basis of his injury.

So, we have a situation wherein the data collection agency risks less by
keeping negative data on subjects, even if it is questionable, than it does by
eliminating negative data.  This fact, combined with the relative financial
positions of the data collection agency and the data purchaser versus the data
subject, puts the subject (i.e., us) at a significant disadvantage.  As far as
I can see, the only remedy to this aspect of the problem lies in making the
data collection agency itself directly liable for all injuries to the data
subject arising from errors in its data.  If our hypothetical traveller is
denied a car and must take a $1,000 round-trip cab ride to Bumbaloosa, east
Washington to make his business meeting, then WRT Data Services should legally
owe him $1,000 (plus court costs if necessary) for the incident.
Additionally, they should be liable for punitive damages if the same erroneous
data causes a similar (or worse) injury at a later data.  The first liability
gives them an incentive to correct the error, and the second liability gives
them an even stronger incentive to prevent the error from recurring.

While I hate to advocate legislation that will increase litigation, the
unfortunate fact is that, without laws and lawyers to level the playing field,
those of us on whom others keep and sell data will remain permanently at risk
from bad data.  It is in our interest to push for such legislation now, before
the data collection agencies become immovable by the Congress (c.f., the
insurance companies).


CFP "Ethics" Workshop Cuba Feb.1994

Klaus Brunnstein <>
Mon, 13 Sep 1993 17:31:54 +0200
CALL FOR CONTRIBUTIONS for an IFIP WG 9.1 Workshop, from Ina Wagner

    Havana, Cuba, February 17-19, 1994

IFIP has been for some time analyzing the possibility of developing its own
Code of Ethics. Working Group 9.1 Computers and Work is planning to contribute
to the discussion on political and ethical problems in systems design,
beginning with a small workshop. The main focus of this workshop will be

* to discuss grounded scenarios which can provide rich knowledge of the
  political and ethical problems encountered in a variety of contexts,
* to analyze the relationships between ethics and the politics of work in
  these contexts (including the work environment of systems designers),
* to develop practical guidelines that help the professional community of
  systems designers to identify political and ethical dilemmas and to
  respond to them.


Ethics and the Politics of Systems Design:

We think of ethical problems as emerging wherever the values and moral
principles on which individuals base their decisions and actions are
contested or in conflict. Such conflicts between people's values, norms of
conduct and claims for moral ground often point to basic underlying
differences between their positions in the organization or in a society,
their interests, and, consequently, their assessment of certain situations.
In that respect, ethical problems have a strong political content.

Real life situations are often characterized by ethical dilemmas involving the
co-existence of conflicting or competing values. The ethical problems that
emerge in a field are shaped by its conditions and contexts, as are the
conflicts that arise between different ethical principles, their different
perception and evaluation by different actors in the field, and the solutions
that participants look for and finally come to accept.  Although high
standards of individual responsibility (as represented in an ethical code) are
indispensable, these need organizational support in order to unfold and
develop. Consequently, the politics of systems design itself need to be a
primary focus of all deliberations on professional ethics.  Questions of
personal morality stand a chance of becoming significant guidelines for action
only if the systemic"questions are openly discussed.  Among these are the work
practices and working conditions of systems designers — management and
development practices as well as the paradigms within which systems designers
are working.

Learning from ethical scenarios:

Ethical scenarios should be grounded in the analysis, development and use
of information technology in different contexts. We think that rich
descriptions of actual conflicts and of how participants cope with them
might sharpen systems designers' awareness of ethical problems in general,
support their analytical understanding and help them enter a dialogue with
others in the field. As WG9.1 we are particularly interested in exploring
the relationships between ethics and the politics of work.

Making ethical principles practicable:

Generalized "ethical codes"  have the advantage that they can act as some
basis for a minimal social standard to be taken into account in systems
design. They oblige systems designers consciously to connect their
technical analysis of a problem with a moral-practical judgement. Two
requirements for such general ethical principles are:

* Their formulation should make clear the consequences of an adequate,
  responsible attitude for the relationships between all participants in a
  design effort.
* They should clearly express the difference and tension between the
  obligation to observe professional norms on one hand and to depart from
  these norms if other principles or the situation make this necessary".

We look for suggestions on how such codes could be developed and made
understood and practicable.

Institutional frameworks for social responsibility:

One particularly difficult task is to set up an institutional framework for
implementing an ethical code and to define the legitimate actors in such a
framework. Analysis of the composition of ethical committees in the medical
area, for example, has brought forward the problems involved in deciding
whether some people are more "affected" or more worthy of participation in
decision making than others because of their education, social background,
specific merits for society or their minority position. Experiments with
citizen participation in communal projects often use drawing lots among the
general constituency instead of elective procedures.

Another question is whether members of such an institutional framework
should be representative of particular groups. It could for example be
argued that otherwise underrepresented actors should be over represented.
This could be justified in a number of ways: A critical mass of members
from that group may be necessary to give weight to their perspective; there
should be sufficient room for the particular values and interests of this
group to be heard.

We look for contributions that deal with these issues on a theoretical and
practical-empirical level (discussing cases, practices).


Participants are invited to submit either:

a)  Ethical scenarios from different types of work organization (from
hospitals to industrial sites) and different cultures (including developing
countries) which are suitable for an in-depth discussion.
    An ethical scenario should
    * be informed by a real case (or cases),
    * include some temporal/historical/developmental account,
    * describe ethical/political conflict in relation to the working
conditions and professional culture of the different communities of
practice involved in the case.


b)  a Position Paper which deals with one (or several) of the leading
issues of the workshop.

Short versions (2-4 pages) should be submitted to:

Ina Wagner, Vienna Technical University, Center for CSCW
Argentinierstrasse 8,  A-1040 Vienna, Austria
Tel: +43 1 58801 4439  Fax: +43 1 5042478  Email:

They will be reviewed by the members of the Programme Committee.


One main result of this workshop will be a position paper for the Reader on
Ethics and Computing edited by Jacques Berleur, Chair of the IFIP Ethics
Task Group. An additional possibility is to revise and expand some of the
contributions for publication in an international refereed journal.


November 1, 1993        Deadline for submission of short version
December 1, 1993        Notification of Acceptance

Given the short preparation time, authors are not expected to send in full
papers before the conference. However, once accepted they will be given
instructions on how to prepare their contribution for the conference itself.


This conference will be connected to the WG9.4 Conference "The Impact of
Informatics on Society: Key Issue for Developing Countries" (from February
21-23 also in Havana). If you are interested in participating in this event
as well, please contact:

Prof. Sam Lanfranco
Centre for Research on Latin America and the Caribbean (CERLAC)
York University (Room 240YL)
4700 Keele Street, North York
Ontario, Canada, M3J 1P3
phone: (416) 736-5237
fax:   (416) 736-5737

Information on the conference site and accommodation will follow. Cuban
Airlines as well as Iberia offer moderately priced flight & accommodation
arrangements. We will inform you about the possibilities in time.


As we have no funding for this conference, we would appreciate participants
to contribute a registration fee (beyond expenses).

Full registration fee: US$ 200
Reduced registration fee: US$ 100


Andrew Clement (University of Toronto), Vice Chair WG9.1
Mike Robinson (University of Aarhus)
Lucy Suchman (Xerox Park, Palo Alto)
Ina Wagner (Vienna Technical University), Chair WG9.1

Please report problems with the web pages to the maintainer