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…
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]
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.
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
> ... 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@cactus.org ...cs.utexas.edu!cactus.org!rdd
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
problem.
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
sater@cs.vu.nl (Hans van Staveren)
rogerb@x.co.uk (Roger Binns)
mathew@mantis.co.uk (mathew)
andyc@cappsdv2.fob.ford.com
wfg!mdavis@uunet.uu.net (Michael T Davis)
taylort@dg-rtp.dg.com (Tad Taylor) .
Several suggested that THEIR mailers are not so stupid, and suggested
various well-known ways of handling the problem. Thanks. PGN]
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
[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%
compatible".
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
related.
Padgett
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. trebor@forEtune.co.jp AnimEigo US Office Email (for general questions): 72447.37@compuserve.com
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
508-836-4711x385 JCook@Epoch.com
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). Rex
CALL FOR CONTRIBUTIONS for an IFIP WG 9.1 Workshop, from Ina Wagner
ETHICS AND SYSTEMS DESIGN: THE POLITICS OF SOCIAL RESPONSIBILITY
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.
THEMES OF THE WORKSHOP
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).
OUTLINE OF THE WORKSHOP
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.
or
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: iwagner@email.tuwien.ac.at
They will be reviewed by the members of the Programme Committee.
OUTCOMES OF THE WORKSHOP
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.
KEY DATES
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.
PRACTICAL INFORMATION
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
email: lanfran@vm1.yorku.ca
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.
WORKSHOP FEE
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
PROGRAMME COMMITTEE
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