Text File

RISKS-LIST: RISKS-FORUM Digest Wednesday 25 May 1988 Volume 6 : Issue 91

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: Computers as a weapon? (Ken De Cruyenaere) Aircraft computer malfunction incidents (Nancy Leveson) Federal "smart cards" (Gary Chapman) Cash on the Nail (Michael Travers via Andrew Scott Beals) Style rules - a horror story (Mark Brader) Rebuttal on Hinsdale (Patrick A. Townson) Risk cost recovery -- Hinsdale (Barry C. Nelson)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, ftp kl.sri.com, get stripe:<risks>risks-i.j ... . Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).

----------------------------------------------------------------------

Date: Tue, 24 May 88 12:02 CDT From: Ken De Cruyenaere <KDC%UOFMCC.BITNET@CORNELLC.CCS.CORNELL.EDU> Subject: Computers as a weapon ?

The following story appeared in today's WINNIPEG SUN (reprinted without permission) Life must certainly be unpleasant in an "occupied land".

COMPUTER NETWORK NABS ARABS RAMALLAH (AP) Israel is using computers as weapon in the struggle to suppress the Palestinian uprising in Israeli occupied Arab lands. A computer linkup of the military administration, police and civil and security service offices allows Israel to monitor almost every aspect of life in the West Bank and Gaza. Arab merchants who obey the calls of the uprising's underground leaders and refuse to pay taxes are often nabbed in a network of computerized roadblocks. On the road between Jerusalem and the West Bank town of Bethelem, an AP reporter saw checkpoints where portable computers were used to track down tax evaders. Names are taken from identity cards Arabs are required to carry. When the names are entered in the computer, it identifies those who owe taxes. The military government demands tax payment in exchange for a registration of a newborn child or marriage, Palestinians told told the AP. "We are scared. The tax officials catch you and seize your car or impose a huge fine." A military government official said about 400 vehicles belonging to deliquent Arab taxpayers have been seized in the West Bank. The computer "is indeed the ultimate instrument of population control, a carrot-and-stick operation", researcher Meron Benvenisti wrote in his annual study of the occupied territories. Benveniti said Israel started to develop a computerized occupied lands data bank in August, 1985. The five-year, $8.5-million project was undertaken by TIM, an Israeli representative of the U.S. computer company Data General.

------------------------------

Date: Tue, 24 May 88 21:12:44 -0700 From: Nancy Leveson <nancy@ICS.UCI.EDU> Subject: Aircraft computer malfunction incidents

From Air Line Pilot, May 1982.

"Several of ALPA's technical committees and the Assocation's New Aircraft Evaluation-Certification Committee are studying improvements that might be made to the stretched DC-9 to address such pilot concerns as the following:

Computer Malfunctions

Unexpected mode changes, complete loss of data, and other anomalies of the flight guidance system have been reported during all phases of flight in Super 80s; cold soaking of the computer or electrical transients or both are believed to have been partial causes. Reports of flight guidance system malfunctions include unexpected switching from the takeoff mode to another mode during the takeoff roll and from the desired approach mode to the heading mode near decision height (DH). Autopilot and autothrottle disconnects during turbulence have been reported, and switching from takeoff mode to climb mode has caused the autothrottle thrust computer to retard one throttle to idle.

Under certain deicing-engine auti-icing bleed configurations and flight conditions -- for example, on coupled approaches and when climbing through cirrus clouds -- problems with computer system logic for digital thrust rating have caused autothrottle disconnects."

[It continues with a listing of problems in non-computer parts of the design.]

------------------------------

Date: Wed, 25 May 88 16:08:06 PDT From: chapman@csli.stanford.edu (Gary Chapman) Subject: Federal "smart cards"

The recent humorous (I presume) recommendation for a universal "smart card" on one's thumbnail prompts me to call attention to something a little more serious. I was recently a reviewer for an OTA draft report on computerizing the entire Federal welfare benefits system--food stamps, Medicare, welfare, etc. As one official put it to me recently, people at OTA thought this was sort of a joke when it first came down, but Congress is serious. The draft report, which may get elevated to a full panel study, considers the issuance of "smart cards" to all Federal welfare beneficiaries, with ATM-like machines at all places where Federal benefits are exchanged for goods and services. If you just stop and think a minute about how many sites this involves--every "Mom and Pop" grocery store, every Seven-Eleven, any place that takes food stamps--you get an impression of the expense. This is a multi-billion dollar proposal just to get the system set up and into place.

Beyond that, say some experts, looms a national identity card for all U.S. citizens. Serious proposals for this may not be far off. So far there has been no real rationale for Congress to consider this, but the recent immigration law, which imposes fines on employers for hiring undocumented workers, will create a nation-wide consitituency pressing for some reliable form of citizenship identification. If there is a trend toward "smart card" disbursement of Federal benefits, this will add to the INS rationale for a national identity card. What's disturbing about all this is that Congress gradually gets used to ideas like these, opposition seems to fade, and the momentum can appear irresistable.

Gary Chapman, Executive Director, CPSR

------------------------------

Date: Wed, 25 May 88 15:29:15 PDT From: well!bandy@lll-crg.llnl.gov (Andrew Scott Beals) Subject: Cash on the Nail

Date: Wed, 25 May 88 16:07 EDT From: Michael Travers <mt@media-lab.media.mit.edu> Subject: Mark O' the Beast update

Subject: Cash on the Nail

DAEDALUS David Jones

For years now, we have been told that the cashless society is just around the corner. Every shop will have a computer terminal; simply enter the transaction, validate it with your personal card, and the central computer will transfer the sum specified from your bank account to that of the shop. Wonderful! The reason why it doesn't happen is that fraud would be so easy. Card fraud is so widespread already that the banks daren't risk anything worse. But Daedalus has the answer. His new cash-card is unstealable: the user's own thumbnail.

A nail has a smooth and uniform surface, and is transparent enough to let through the light from a laser. A small laser could bring a brief light pulse to a focus in the body of the nail, burning a tiny white mark that could easily be read, but would be protected from chance abrasion. A dot-matrix pattern of such marks could easily encode a financial transaction. A nail has no nerves so the process would be quite painless. Accordingly, the new Dreadco financial terminal has, besides a keyboard for entering the transaction, a thumb-port to admit the user's thumb.

Every day a nail grows about a tenth of a millimetre. With laser dots about the size of those on a compact disc , this would give space for about ten new transactions. Over time the user will accumulate on his thumbnail a running financial statement showing all his transactions for the past few months. Each time he inserts his thumb into a terminal, the sytem will check that statement against its file. If everything matches, his identification is secure; the terminal accepts the new transaction and prints it below the previous ones. But if there is a discrepancy, it sounds an alarm and clamps down on the suspect thumb, trapping the fraudster until the police arrive!

But suppose a bent manicurist manages to photograph a client's thumbnail, and uses it to construct a forged thumb? Even then, the fraud is risky. By the time the forged thumb is ready, the victim will probably have used the system again. The forgery will not carry this latest transaction: it will be detected and trapped by the terminal, for the police to study later as evidence.

Daedalus' new thumbcard will impose financial prudence on its users. The spendthrift who fills his thumb up with wild transactions will soon be choked off by sheer lack of space. On the other hand, should he go down with mumps or measles (which arrests nail growth) bankruptcy would rapidly threaten. And secrecy is not really assured. Gigolos with magnifiers may shrewdly revive the old gallantry of hand-kissing: gypsy palmists will read both sides with great care; shady financial operators of both sexes may take to wearing opaque nail varnish. And a death in the family will have the sorrowing relatives hastily erasing the deceased's thumbs with a laser-scrambler, before some unscrupuous undertaker or body-snatcher can detach or copy them to filch their encoded legacy.

The Guardian, 24 May l988

------------------------------

Date: Wed, 25 May 88 20:33:49 EDT From: msb@sq.com (Mark Brader) Subject: Style rules - a horror story (forwarded from comp.lang.misc on USENET)

On the topic of corporate rules requiring formal documention for each procedure in a program, Dick Dunn (uucp: {ncar,cbosgd,nbires}!ico!rcd) posted the following in comp.lang.misc:

People may not realize just how much trouble it can cause. A few years back, I saw a procedure-heading standard which was so large and ornate that it was actually causing people to *avoid* writing procedures! They were working on a project which had deadlines (as opposed to lines-of-code-per- day goals:-), but they were absolutely required to build one of these giant headers for each function. As a result, it was often easier to write code in-line to perform the identical function in several different places than to split it out into a separate procedure.

Write your own moral--something about programmers taking the easiest path so style rules should encourage the easiest path to be the same as the right one.

Forwarded to Risks by Mark Brader

------------------------------

Date: Wed May 25 20:40:09 1988 From: Patrick_A_Townson@cup.portal.com Subject: Rebuttal on Hinsdale

John Haller of AT&T Labs (Risks 6.90) discusses the sequence of events which led to the disasterous fire at Hinsdale on May 8. He quotes from a television show (Chicago Tonight) which on more than one occassion has been derelict in getting all its facts straight.

First: The fire alarm and power outage alarm were NOT simultaneous. The fire alarm was first noted in Springfield, IL at 3:50 PM that Sunday afternoon. The fire alarm signal continued for nine minutes. It was ignored by an employee who thought it was going off due to other conditions at the time.

The alarm stopped about 3:59 PM, then started again a few minutes later, and on its second warning, *then the alarm for loss of power made itself known*. There was nine minutes wasted, plus the several minutes until it began again.

Second: When the technician finally was moved intellectually to consider that a fire alarm might actually refer to a fire, a call was made to a weekend duty supervisor. Not the Hinsdale Fire Department; not the Police Department, but a person who had to put down what they were doing, go out to their car and drive to 120 South Lincoln from wherever they were, through Sunday traffic, the whole bit. Had the tech immediatly called the Hinsdale Fire Department and the weekend supervisor, and coordinated as best as possible the arrival of firemen with telco personnel on location, the damages would have been much less.

Third: The cost of staffing for that office, or any central office on weekends or off hours is no where near the estimate given by correspondent. He assumes a full compliment of people on each shift, Sundays, nights, holidays, etc... and assumes holiday pay, night premiums, etc. None of this is required. One or two persons *maximum* per office would be fine. A clerk at a terminal with work to do -- they surely could input work orders, make record corrections, etc -- and the express duty of touring the building once every hour or so and immediatly upon reciept of an alarm would be sufficient.

Fourth: A good, comprehensive Halon network, via overhead plumbing just as in conventional water sprinkler systems, would cost only about a quarter million dollars per office to install, and much less than that annually to refresh the holding tanks each year. Hand held halon extinquishers mounted in strategic locations around the building would cost even less.

Imagine if you will, a clerk on the premises Sunday afternoon. He is only paid $30,000 a year or so, and an alarm is noted on his console or terminal. He picks up a hand held cellular phone, walks into the room down the hall, sees smoke and grabs the Halon cannister from the wall. On the phone he dials 911 to tell them. He starts spraying the Halon, and likely gets the fire out before the firemen arrive. Then he calls a couple other numbers on the phone to key employees to get the word out: get over here fast.

He goes out, meets the firemen and escorts them inside. If the fire is still going, they also have Halon, and are better trained at this sort of thing than the $30,000 per year clerk. Within minutes a couple of other employees are there, and the limited damage is assessed and repairs begin immediatly.

Now how much would this very *non* labor intensive scenario cost in a year? We would need three such persons per office -- or four perhaps -- allowing for one at night, one evenings, one weekends and days off for the other two.

Would $200,000 per year per office cover salaries? If there were 10 very important central offices in the Chicago area, would $2,000,000 per year cover salaries? That's quite a bit lower than the $12,000,000 correspondent suggests would be required. And if the watch-persons had other duties to do, could their salaries at least in part be charged off in the budgets of other departments? In my figures here, I've actually over-budgeted to include two or three additional watch-persons-at-large, who would travel from office to office during the night to relieve for lunch breaks, fill in for sick or vacationing watch-persons, etc.

Correspondent shudders at the idea of $12,000,000 (his figures), and says its not economical....but the actual damage to date from Hinsdale has exceeded $50,000,000 and the cash register is still ringing! Talk about false economies....

I'm sorry, but I think Jim Eibel, Illinois Bell VP of Operations, and designer of the plans which led to this tragedy was expecting an awful lot for his money if he figured a person downstate would see the alarm, know what it was, get help and control a serious problem as well as someone right on location babysitting the switch would do it.

Finally, they have weekend duty supervisors all over the area anyway. They are already being paid a salary, so in figuring the cost of staffing an office at night you have to consider you already have several of the needed employees in place. Arrange them differently and hire a few more.

I rest my case.

Patrick Townson

------------------------------

Date: Wed, 25 May 88 09:41:37 EDT From: "Barry C. Nelson" <bnelson@ccb.bbn.com> Subject: Risk cost recovery

John Haller writes about economics of protecting telco switches:

> At a typical salary of a >craft person, that would be ~$120,000 per year per office. To >staff 100 offices, at $12,000,000 per year, it is easy to see >the decision not to staff compared to the cost of a new switch.

Okay, so I'm not an 'econ' major, and it isn't very easy for me to see this.

It does NOT take a craft person to watch a switch, it takes a security guard (and I would guess they would not be paid as well!). The CRAFTperson, if provided, could be doing otherwise-useful work while guarding the switch. Such work could not be fully billable as 'protection', and the TelCo would benefit materially.

Ten minutes out of an hour to do 'rounds' leaves 3/4 time 'working.' Add this to the demonstrably fallible alarms already installed and they are made much better since a person on-site can EASILY go LOOK, let alone COPE with a problem immediately.

Why not just reduce daily staffing so as to normally have productive work to do during off-hours. Even paying an EXTRA 1/4, or $30,000 per year per office, exclusively for added protection, is pretty cheap for guaranteed insurance.

We must also not forget the other costs beyond the actual switch. [From Patrick Townson's May 14 posting to RISKS:]

> And twenty five million is a *very >low estimate* of the cost of the fiasco. The new switch alone is estimated >to cost about sixteen million dollars. ... That does >not of course include peripheral equipment, overtime salaries to workers, >the cost of repairing the building or the month of lost revenue from the >thousands of subscribers without service.

I'll bet someone with the ACTUAL number of similar offices, over all the years they've been installed, given the ACTUAL distribution and cost of preventable disasters during those years, could come up with a good business case for continued protection. Belt and suspenders, anyone?

Barry C. Nelson

------------------------------

End of RISKS-FORUM Digest ************************