Text File

RISKS-LIST: RISKS-FORUM Digest Tuesday, 23 February 1988 Volume 6 : Issue 30

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

Contents: The risks of pressing the wrong key -- a taxing situation (Gligor Tashkovich) Taxing of information (Steven Koinm) Using viruses for copy protection (Doug McIlroy) What's in a Name, III (Vint Cerf, John Pershing) Re: Mistaken Identity (Amos Shapir) Details of bank's costly computer foul-up (Rodney Hoffman) Voice-print security (and Rory Bremner) (J M Hicks) Auto-mated Citations (Mark Brader) Re: Shuttle Security (Henry Spencer)

[There is a mass of messages pending on Trojan horses and Viruses. I may put out an issue or two dedicated to that subject. PGN]

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. > > > > > > > > > PLEASE LIST SUBJECT in SUBJECT: LINE. < < < < < < < < < For Vol i issue j, FTP SRI.COM, CD STRIPE:<RISKS>, GET RISKS-i.j. Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).

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

From: gligor%lerouf.DEC@decwrl.dec.com (Gligor Tashkovich) Date: 21 Feb 88 13:01 Subject: The risks of pressing the wrong key -- a taxing situation

Coopers & Lybrand did my rough French taxes on Friday (courtesy of Digital) by computer. When the agent went to pull a screen of information that he had entered on me, he pressed the wrong key and up came personal tax information that was for another employee of Digital in my subsidiary. All the important confidential information was there including salary, real estate owned, etc.

The risk here is that information that you give to a tax person on a confidential basis might not be that confidential after all ...

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

From: Steven Koinm <goog@a.cs.okstate.edu> Subject: Taxing of information Date: 17 Feb 88 07:48:28 GMT Organization: Oklahoma State Univ., Stillwater

I recently came across an interesting idea presented by a hacker while doing research for a paper. The hacker said that he could not consider information property because it cannot be taxed.

But, what if it could. How would you put a property tax on information? How can you say what the value of that information is? It may be invaluable to you but it's still just a bunch of bits unless it is used? Maybe if they were to keep track of each time you used a piece of information and then based the amount of tax on that?

Would this make people stop collecting HUGE amounts of information that they keep around just for the sake of "I'll need that someday" or "Why bother erasing it, it may still be valid."

I just thought that this was an interesting thought...

GOOG ?? (a.k.a. Steve Koinm) Computing and Information Sciences Internet: goog@a.cs.okstate.edu Oklahoma State University UUCP: {cbosgd, ihnp4, Stillwater, OK 74075 rutgers}!okstate!garnett

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

From: doug@research.att.com Date: Mon, 22 Feb 88 08:17:49 EST Subject: Using viruses for copy protection

I've not heard actual instances of latent viruses being used for copy protection, although one of your correspondents asserted that had been done. Anybody contemplating such a gimmick, however, had better think twice. If you booby trap your house and injure a burglar, or if you string a wire across a hikers-only trail and decapitate an illegal biker, you are criminally liable.

Doug McIlroy

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

Date: 21 Feb 1988 00:20-EST Subject: Jr., Sr., III (RISKS-6.29) From: CERF@A.ISI.EDU

RE: Mr. William E. Brown III, it's a good thing his name isn't William W. Brown III or his card would read W W III !!

RE: systems that don't deal with trailers on names like Jr., Sr. or III, MCI Mail specifically parses for these. Vint

[Because Vint does not have one of these trailers, he cannot be accused of being Self-Cerfing. PGN]

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

Date: 23 Feb 88 11:22:11 EST From: John Pershing <PERSHNG@ibm.com> Re: W E III

The letters that I find most amusing are the ones that I get every couple of months that start out long the lines of:

A personal message for JOHN A PERSHING JR:

Dear Mr. Jr: ...

Also, back when I was in college, our fraternity was listed in the phone book as "Kappa Sigma Frat". One day, we got a bulk mailing declaring "Good News for the Frat Family" addressed to Mr. K.S. Frat, claiming that an arduous genealogical search had turned up the Frat Family coat of arms, which they wanted to send to us (for a price, of course).

John A. Pershing Jr., IBM, Yorktown Heights

[Live off the Frat of the Land and operate under a strict Coat of Alms. PGN]

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

Date: Mon, 22 Feb 88 09:27:57 PST From: Amos Shapir NSTA <amos@nsc.NSC.COM> Subject: Re: Mistaken Identity (RISKS DIGEST 6.29)

The Israeli state collection agency issued a warrant for the arrest of a debtor; since they had only his name (a rather common one) and the town he lived in, a clerk completed the missing information - full address, ID number and father's name - from the first entry for a person of the same name he found in the citizen's registry. That person had a very hard time (including an overnight arrest) explaining to the authorities that it's not him ("but it is *your* ID on the arrest form, isn't it?!"). Amos Shapir

National Semiconductor 7C/266 1135 Kern st. Sunnyvale (408) 721-8161 amos@nsc.com till March 1, 88; Then back to amos%taux01@nsc.com

[This one is computer-related in the sense that input data should acquire an appropriate measure of trustworthiness and then be handled accordingly. That measure should stay with the data, as is the case with a security label. PGN]

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

Date: 7 Feb 88 18:36:54 PST (Sunday) Subject: Details of bank's costly computer foul-up From: Rodney Hoffman <Hoffman.es@Xerox.COM>

In RISKS-5.16 (25 July 1987) and again in RISKS-6.16 (27 January 1988), I related news accounts of Bank of America's failed attempt at an ambitious new trust accounting and reporting system.

The Los Angeles Times for Sunday, February 7, 1988, carried a lengthy front-page review of the entire debacle, "B OF A'S PLANS FOR COMPUTER DON'T ADD UP" by Douglas Frantz. The article includes lots of background history and economics. Here are a few edited excerpts giving more details than the previous accounts:

Last month, Bank of America acknowledged that it was abandoning the $20 million computer system after wasting another $60 million trying to make it work. The bank will no longer handle processing for its trust division, and the biggest accounts were given to a Boston bank. Top executives have lost their jobs already and an undisclosed number of layoffs are in the works.

...The total abandonment of a computer system after five years of develop- ment and nearly a year of false starts raises questions about the bank's ability to overcome its technological inadequacy in an era when money is often nothing more than a blip on a computer screen....

In 1981, the bank had fallen far behind in the computer race. Then-new chairman Armacost launched a $4-billion spending program to push B of A back to the technological forefront. The phrase he liked was "leap- frogging into the 1990s," and one area that he chose to emphasize was the trust deparment....

The bank was mired in a 1960s-vintage accounting and reporting system. An effort to update the system ended in a $6-million failure in 1981 after the company's computer engineers worked for more than a year with- out developing a usable system.....

In the fall of 1982, bank officers met Steven M. Katz, a pioneer in creat- ing software for bank trust departments.... In 1980, he had left SEI Corp. in a dispute and founded rival Premier Systems.

Katz insisted on using Prime instead of B of A's IBM computers. He boasted that he could put together a system by 1983. Within six months, a B of A - led consortium of banks agreed to advance Premier money to develop a new, cutting-edge system for trust reporting and accounting. Nearly a year was spent on additional research.... The go-ahead to fund to project came in March, 1984. While it was not a deadline, the goal was to have the new system in operation by Dec. 31, 1984.

What followed was a textbook structure for designing a computer system. A committee was formed of representatives from each B of A department that would use the system and they met monthly to discuss their requirements. DP staff gathered for a week each month to review progress and discuss their needs with the Premier designers. Some of the DP experts found Katz difficult to deal with occasionally, especially when they offered views on technical aspects of the project. "Don't give us the solutions. Just tell us the problems," Katz often said.

When the ambitious Dec. 31, 1984, goal was passed without a system, no one was concerned. There was progress, and those involved were excited about the unfolding system and undaunted by the size of the task. B of A devoted 20 man-years to testing the software system and its 3.5 million lines of code; 13,000 hours of training, including rigorous testing, were provided to the staff that would run the system....

In spring 1986, the system was about ready. Some smaller parts were already working smoothly. Test runs had not been perfect, but the technicians thought most bugs could be worked out soon. A demonstration run had been successful....

Many employees were operating both systems, working double shifts and weekends. Late in 1986, an anonymous letter warned against a "rush to convert" to the new system and told the manager, not a computer expert, that people had "pulled the wool" over his eyes. The executive assured the staff that there would be no conversion before it was time. By then, lines of authority had also changed, making cooperation difficult.

By early 1987, tests had been running with only a few bugs. "There were still bugs, but the users felt they could run with it and work out the bugs as we went along," one former executive said. A conversion date was set: March 2, 1987.

Just then, half the DP staff was pulled off the assignment. The conversion lasted one week. On March 7, the first of the 24 disk drive units on the Prime computers blew up, causing the loss of a portion of the database. It was past midnight each night before workers retrieving data from a backup unit left the offices. Over the next month, at least 14 more of the disk drives blew up. None had malfunctioned in the previous months of test.

It turned out that the units were part of a faulty batch manufactured by Control Data Corp. But by the time the cause was discovered, delays had mounted and other difficulties had arisen. Taken individually, none would have caused the ensuing disaster. Together, they doomed the system.

At the same time, the bank decided to move the main staff 30 miles away. Key people quit and morale sank. Another section of staff was told they would be moving from Los Angeles to San Francisco, with many losing their jobs. [Conflicts, turf battles, consulting firms, temporary employees]

The bank's first public acknowledgement of the problems came in July 1987. [See RISKS-5.16] An in-house investigation was viewed by many staff mem- bers as a witch hunt. The bank announced further costs and then the trans- fer of the accounts in January 1988. [See RISKS-6.16]

The bank's one-time head of the program, since resigned, says, "A lot of people lay down on the floor and spilled blood over this system, and why they abandoned it now I cannot understand. A guy called me this morning out of the blue and said that 95% of it was working very well."

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

From: J M Hicks <cudat@DAISY.WARWICK.AC.UK> To: RISKS@COM.SRI.CSL Subject: Voice-print security (and Rory Bremner)

On Saturday 20th February, the B.B.C. Radio 4 programme "Money Box" broadcast an item about a service provided by a bank in Britain. (I didn't catch the name of the bank --- a pity.) The service is provided by telephone. No mention was made about any kind of secret personal code to confirm the identity of a customer --- security is afforded by the bank's computer's memory of one's "voice-print", i.e. it can tell who you are just by listening to your voice. I believe "funds transfer" is one of the services provided.

The representative of the bank was asked about the possibility of someone impersonating a customer. He replied that the bank had engaged Rory Bremner, a well-known mimic, to try to mimic other people and deceive the computer. Rory couldn't.

Suppose someone recorded someone else's voice and played that down the telephone line? (I think the recording would have to be made while the victim was using the service, though --- after speaking each digit to the computer one has to wait for a confirmatory beep. Ordinary fluent speech would not do.)

What do readers think of the idea of dispensing with the secret personal code?

(Respondents should bear in mind that few people in Britain have telephones with multi-tone dialing.)

J. M. Hicks (a.k.a. Hilary), Computing Services, Warwick University, Coventry, England. CV4 7AL On JANET: cudat@UK.AC.WARWICK.CU (in the U.K.) On uucp: ...!ihnp4!mcvax!ukc!warwick!cudat

[Distressing to see the old argument, "Our best forger couldn't break it, so it must be pretty good." Voice-prints are difficult to mimic by voice, but easy to spoof by playback attacks. On the other hand, personal codes (PIN numbers) are also not wholly dependable. RISKS readers know by now that just about every attempt to gain user convenience has some intrinsic vulnerabilities. PGN]

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

Date: Mon, 15 Feb 88 22:13:02 EST From: msb@sq.com (Mark Brader) Subject: Auto-mated Citations

Following are excerpts from a Usenet discussion going on in the newsgroups sci.electronic, rec.autos, and (!) rec.ham-radio. The excerpts were selected, sequenced, and forwarded to RISKS by Mark Brader.

John Moore (john@tower.UUCP):

Here in Paradise Valley, Arizona, we have the dubious distinction of being the only place in the US where speeding tickets are given by mail after an automatic device snaps your picture and speed!

Norm Strong (strong@tc.fluke.COM):

Most countries in the world hold the owner responsible for speeding, regardless of who's driving. This isn't possible in the US because we have a constitution that prohibits it.

Richard Welty (welty@sunbarney.UUCP):

This* proves to be alterable via local statute. Communities that are trying out the robocop have altered their laws so that they may charge the owner if said owner refuses to identify the driver at the time of the infraction. I wonder if the owner gets any points from this ... [* No, he didn't mean the US constitution -- msb]

Ron Natalie (ron@topaz.rutgers.edu):

I was wondering when someone was going to bring up the question of "it's not me driving." I have no idea how Arizona deals with it, but a friend who was stationed in Germany told he how it is dealt with there. If the driver in the picture is not positively identifiable as you, they will let you off on the provision that you log whereever you drive. Hence, if you get your picture taken again, you will have a before the fact record of if you were there. Not keeping your log truthfully is a serious offense.

Mad Matt Schaefer (matt@cs.wisc.edu):

I've heard of this system in Europe (Germany?) and somebody told me that it became unpopular with government officials and other important people because the ticket and picture came in the mail while the guy was at work and his wife opened it and saw the picture of the car, plate, speed, husband, and *the other woman* in the car with him. I thought, "this guy is not gonna get the welcome he is expecting when he gets home."

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

Date: Sat, 20 Feb 88 18:44:47 EST From: mnetor!utzoo!henry@uunet.UU.NET Subject: Re: Shuttle Security

> ... 7 packages of microfilm classified "Confidential" were left > unsecured for 8 months. Each package of microfilm contained 181 sheets, > listing 4,205 confidential radio frequencies ... > What does this do to a risk analysis of shuttle safety? ...

Probably nothing much. There is NO SUCH THING as a "confidential radio frequency" if it is in active use. It's just not that hard to eavesdrop enough to find out which frequencies are being used, and make good guesses about what they are being used for. (For example, triangulation will tell you which transmissions are coming from the range-safety transmitters.) The real security of the system rests on the secret codes used to trigger action, and on the difficulty of outshouting the range-safety transmitters (which send continuously at high power to make it hard for a false signal to be heard). Refusing to publish the frequency is just an extra obstacle, and not a very important one.

This whole thing sounds like a tempest in a teapot, actually. "Confidential" is not a very high classification. Long odds that nothing of real importance was in those microfilms.

Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry

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

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