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…
After more than 30 years of accumulated evidence to the contrary, the U.S.
Defense Department apparently still believes that so-called command-control-
communications (C3) systems should be designed and built from the top down as
fully integrated systems. While that approach may have some validity in the
design of weapon systems, it simply doesn't work for systems intended to gather
information, aid analysis, and disseminate decisions. The top-down approach
has wasted billions of dollars so far, with more to come, apparently.
I noticed the citation in RISKS 9.52 of the article, "The Pentagon's Botched
Mission," in DATAMATION, Sept. 1 1989, which describes the latest development
failures in the World Wide Military Command and Control System (WWMCCS). The
cited article indicates that they are still following the same misguided "total
system" approach that helped me to decide to leave that project in 1965. I
confess that it took me awhile to figure out just how misguided that approach
is — I helped design military computer systems for 11 years before deciding to
do something else with my life.
In RISKS 9.56, Dave Davis and Tom Reid observe that current C3 development
projects seem to be sinking deeper into the mire of nonperformance even as the
plans for these systems become more grandiose and unrealistic.
Please understand that I am not arguing against top-down analysis of
organizational goals and functions. It is clearly essential to know which are
the important responsibilities of an organization in order to properly
prioritize efforts. Based on my experience, attempts at aiding analysis and
decision-making tasks with computer applications should begin with the lowest
levels and proceed upward IN THE CASES THAT WORK. Contrary to some widely held
beliefs, many such tasks do not lend themselves to computer assistance and the
sooner one weeds out the mistakes and intractable tasks the faster one can
improve the areas that do lend themselves to automation and integration.
A great deal of time, effort, and money can be save by approaching development
in an evolutionary bottom-up way. It is essential to shake-down, test, and
improve lower level functions before trying to integrate at a higher level.
Trying to do it all at once leads to gross instability that takes so long to
resolve that the requirements change long before the initial version of the
system is "finished." Each time one moves up a level it is usually necessary
to redesign and modify some or all of the system. It is much faster to do that
a number of times than it is to try to build a "total system" the first time
because that approach almost never works.
Someone (Karl von Clausewitz?) once said that people who don't know history are
condemned to repeat it. A modern corollary is that people who do know history
will choose to repeat it as long as it is profitable. Unfortunately, the
Defense Department's procurement policies often reward technical incompetence
and charlatanism. I will support this claim with a few "peace stories" that
would have been much more atrocious "war stories" if any of the systems that we
designed had been involved in a real war. Fortunately, that didn't happen.
The presumption that computer-communication system development should be done
on a grand scale from the outset is just one of many bad ideas that have taken
root within the military-industrial establishment. The reason that this
misconception has persisted for decades is that there is no penalty associated
with failure. On the contrary, failures are often very profitable to the
contractors — the bigger, the better. The bureaucrats who initiate these
fiascos usually move on before the project fails, so if anyone tries to point
fingers they can say that it was the fault of the subsequent management.
While the "total system" approach is one of the more persistent causes of
failure in C3 development, it is by no means the only misconception afloat. In
subsequent segments I will review some other causes of historical fiascos. All
of this will be ancient history, since I got out of this field about 25 years
ago. Of course, many of the more recent fiascos are protected from public
scrutiny anyway by the cloak of national security.
(Next segment: a SAGE beginning.)
-Les Earnest (Les@Sail.Stanford.edu)
Yellow Cab in San Francisco is using a dash-mounted computer in each taxicab to facilitate dispatching and supposedly to prevent dispatchers from favoring particular drivers. However, the system ($800,000) ``remains plagued by breakdowns and by drivers grumbling that foul-ups mean a loss in income.'' "When the system is on line, it works well," said Leon Collett, first vice president of the cab firm. "But we have had transmitter problems, hardware problems, software problems." ... [Computer Snarling Yellow Cabs in S.F., Maitland Zane, San Francisco Chronicle, 15 Jan 90, p.A2.]
There's no horror story to go with this, we wised up in time... Recently, we aquired two Sun SparcStation-1s. We only bought 1 100Mb drive for each from Sun and we're (still) waiting on shipment of our CDC drive. To save space, I only installed the basics: /, /usr, development tools, and a couple of other goodies. I did *not* install the man pages, as they took up around 6Mb of badly needed space. Then I had an idea: Mount /usr/man from our DECstation 3100 as /usr/man on the sparc-1s. It worked, and I sent mail to all accounts saying that the man pages were from Ultrix/BSD, and probably shouldn't be trusted in critical apps; they were just there for ease of remembering things like which ls(1) flag does what. The next day there's mail telling me I've screwed up. There *are* man pages for the sun, and I've mounted DEC3100:/usr/man pages over them. I typed "man ar", and sure enough, there were man pages with Sun Release 4.0 Last change: RISC <pagenum> at the bottom of each page... I was astounded. Luckily, the ar commands my prof needed must have been the same, as no data was lost, and everything worked. I dismounted all nfs, and looked at /usr/man — nothing was there. "man ar" returned an error about not finding the man pages. A little experimentation shows that the SunOS 4.0.3-4c man command inserts the above line in the formatted man pages. I think it's presuming a little too much to go ahead and cite the source/version of a manual page from within the formatting program... J. Eric Townsend, University of Houston Dept. of Mathematics
... It takes more than minute
for this particular CDROM to come online, during which time the
Macintosh is busied out, thus the inexplicable delay....
Part of the blame for this confusion can be laid squarely on
Apple. Their own Human Interface Guidelines specify that the
pointer should be replaced with a watch for a "lengthy
operation" (Inside Macintosh p.I-37). They often follow their
own guidelines, but not in this case.
This is probably one of those cases in which an implementation in one
part of a complex system (the CD-ROM drivers) invalidated a simplifying
assumption which had been made in another part of the system (the Finder).
During normal operations, it takes very little time for the Mac operating
system to process a "disk mount" event. The current application (the Finder,
in this case) calls MountVol(), which reads in the volume information
and adds the necessary entry to the drive queue. The delay is usually
less than a second, and so the Finder's author didn't consider it a
"lengthy" operation which required putting up the stopwatch-cursor.
There are a couple of circumstances in which this assumption turns out
to be invalid, though. One of them is when the volume being mounted
is a CD-ROM which adheres to the ISO 9660 standard.
The Mac operating system keeps track of the number of files available
on each volume, and the Finder can display the counter. However, ISO
9660 CD-ROMs don't store this value in their headers. So, when you
mount a new CD-ROM, the Mac's "Foreign File" code quite politely
calculates the file-count, by stepping through the disk's directory!
As you've noticed, this can take a loooooong time!
Unfortunately, there's no practical way for the Finder to tell that
it's about to mount an ISO 9660 CD-ROM until _after_ it has done so.
>From the Finder's point of view, the MountVol() call is an atomic
operation... one which takes a long time to return, it's true, but
one which is not divisible into a look-first/do-it-now couplet. Hence,
the Finder can't tell that it should [have] put up a stopwatch, until
it's too late!
Fortunately, this issue will probably be moot when the new version of
the ISO 9660 Foreign File code is released by Apple. I've heard that
Apple has eliminated the scan-the-directory-and-count-the-files process;
it's too much work to do, for a small bit of information which is rarely
used or useful.
Presumably, the new driver-code will be available through Apple dealers at no
cost. It would be adding insult to injury for Apple to tell users that they'd
have charge this Fur'in File code on their Apple Fee Line.
Dave Platt, Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 (415) 493-8805
A large computer manufacturer (which my friend prefers remain anonymous) laid off 7% of its employees just before Labor Day. My friend, who works there, and who I will refer to as 'Pat', was told he/she was not in the group to be terminated. However, when Pat called Saturday to get phone mail, Pat found his/her phone mail box no longer existed. Pat also could not log on to the company computer system. Needless to say, Pat was worried over the weekend. When Pat went to the plant on Tuesday, the magnetic badge would not open the computer-controlled door. After some investigation, it turned out that a data entry operator had made some errors in entering employee numbers, and indeed Pat along with a few others in the same boat were still supposed to be employed. It took 36 hours before all of Pat's computer-controlled privileges could be restored, (apparently, there was no procedure for correcting errors of this sort). Finally, some weeks later, Pat found that all of Pat's accrued vacation days had been reset to zero!
Here's a short article on the risks of having an 800 number.
The 1/12/90 San Diego edition of the Los Angeles Times had the following
article (first, a little background, Joan Kroc is having trouble finding a
buyer for the San Diego Padres):
It started with a joking headline on Times sports editor Dave Distel's
column on Thursday: "Have a Credit Card Ready and Call Now! 1-800-BUY-PADRES."
Richard Cole, co-owner of Emslee Products of Cleveland, Ohio, is not laughing.
His company sells sanitary napkins. Its number is 1-800-BUY-PADS. "Our phone
has been ringing all day," Cole said. "My secretary can't get any work done,
I'm losing orders, I'm paying 12 cents per minute for every call, what in hell
are you people doing out there?" [...]
Steve Grabhorn, Code 645, Naval Ocean Systems Center, San Diego, CA, 92152
It's the careless attitude that a computer password is no different than a
house key that literally opens businesses and government to fraud and espionage.
The difference between loaning someone your house key and you passwordd is
simple. You own your house (or the bank does :) ), but your password and the
resources that it protects are not yours, or yours to lend.
In addition, one loaned password can affect many people, even an
organization, if abused - or misused, for that matter.
Lending and trust are key concepts in a democratic society, and
important in social interaction. Yet in the electronic society that we
live in, where a single password can affect people's lives, prudence
and adherence to good security policies are just as important.
Dave Bafumo
Rochester Institute of Technology Criminal Justice/Computer Science (Student)
CALL FOR PAPERS
COMPUTER SECURITY FOUNDATIONS WORKSHOP III
June 12-14, 1990
Franconia, New Hampshire
The purpose of this workshop is to bring together researchers and
practitioners in computer security to examine current theories of
security in computing systems, with attention to the system models that
provide context for such theories and techniques for verifying security
as defined by these theories.
The workshop will include paper presentations, panel sessions, and
participation in working groups. Papers and proposals for both panel
sessions and working group problems are solicited in any application of
formal methods from computer science, mathematics, and logic to
computer security. Possible topics include security models, covert
channel definition and analysis, information flow, access control,
secure protocols, and verification techniques.
Instructions for Participants: Workshop attendance will be limited to
thirty-five participants. Prospective participants should send four
copies of a paper, panel proposal, or working group proposal to John
McLean, Program Chair, at the address below. Submissions must be
received by February 15, 1990. Participants will be notified of
acceptance by March 15, 1990. Papers will be published in a
proceedings that will be available at the workshop.
Program Committee:
Janice Glasgow Daryl McCullough Jon Millen
Bob Morris Ravi Sandhu Marv Schaefer
For further information contact:
General Chair: Program Chair:
Tom Haigh John McLean
Secure Computing Technology Corp. Code 5540
2855 Anthony Lane, Suite 130 Naval Research Laboratory
St. Anthony, MN 55418 Washington, DC 20375
(612) 782-7145 (202) 767-3852
haigh@dockmaster.arpa mclean@itd.nrl.navy.mil
Publications Chair:
Bill Young
Computational Logic, Inc.
1717 W. 6thSt, Suite 290
Austin, TX 78703
(512) 322-9951
young@cli.com
Please report problems with the web pages to the maintainer