RISKS-LIST: RISKS-FORUM Digest Monday 30 January 1989 Volume 8 : Issue 18 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Hong Kong computer horse betting (George Moore) Keycard badges vs. anti-shoplift systems (Bruce Hamilton) Bank Fraud (Peter Golde) Crashing a PDP-11/40 (Computer Folklore) (Jeff Makey) Sprint to the Finish? (Steve Philipson) Information Security/Computer Crime Statistics (Stan Stahl) Re: ELIZA and Joe Weizenbaum (Bernie Cosell, Bob Krovetz) Virus conference hosts software swap meet (Robert Lee Wilson Jr) Structured Programs, Project Failures (Charles J. Wertz) Losing Systems (Mike Albaugh) ---------------------------------------------------------------------- Date: Sun, 29 Jan 89 06:16:26 -0500 From: georgem@microso.UUCP (George Moore) Subject: Hong Kong computer horse betting Tonight's "Beyond Tomorrow" program on Fox television did a short article about a device that is currently under test in Hong Kong. It is a portable (slightly larger than a calculator) terminal which allows a user to place bets on horse races from anywhere that has a modular phone connection. It has 6 touch-sensitive LCD windows which present various menus allowing the person to place up to 100 bets per race. Once all of the bets are entered, you just connect it to the phone line and it dials up the computer at the race track. Your account number is stored in the (presumably) EEPROM of the device; all you have to enter is a 6 digit PIN number to identify yourself. Money won or lost is automatically reflected in your bank account. The RISKS implications are enormous. People are currently grumbling on how unsecure an ATM is. That's nothing compared to this! At least with an ATM you have leased lines that are slightly harder to tap, with this wonderful device all someone has to do would be to tap a phone extension in your house or office and grab your PIN number. Even if it's encrypted, the thief will have plenty of time to break the code offline. After that he's free to deplete your bank account. With the proper fake ID, he could freely collect his winnings at the race track. Why gamble with your own money? Use someone else's! The American Horse Racing Association is looking heavily into using this device in the U.S. to relieve overburdened telephone operators at most race tracks. I for one, even if I *did* frequent the tracks, would never trust such a device over ordinary phone lines. -George Moore ------------------------------ Date: 28 Jan 89 17:00:10 PST (Saturday) From: "Bruce_Hamilton.OsbuSouth"@Xerox.COM Subject: Keycard badges vs. anti-shoplift systems Here's a new one. In Xerox/El Segundo we use these big heavy blue keycard badges that you slap against (or hold near) a reader to open various doors. Today I went shopping in the local Target store and as I tried to exit, all sorts of lights and bells went off. You guessed it -- the badge was responsible. The guard apologized and gave me a little piece of cardboard labeled "SCHLAGE SHIELD" to put next to my badge. Of course, when I got to work, I had to remove the cardboard to get the badge to work. --Bruce [Interesting. The same mechanism is used for entry control at Xerox and exit control (anti-theft) at Target. The moral unfortunately is that the SCHLAGE SHIELD works fine to circumvent the anti-theft control. Here is another supposedly high-tech solution with a trivial bypass. Ho-hum. PGN] ------------------------------ Date: Sat, 28 Jan 89 22:47:49 EST From: Peter Golde Subject: Bank Fraud A few days ago I saw a program on TV dealing with bank fraud and mismanagement. One of the reports went somewhat as follows: An employee in the computer division, who had been working at the bank less than a year, one day sent a computer message to the Brinks depository which stores and handles gold bullion for the bank. The message simply asked for Brinks to send 44 kilos of gold to such and such P.O. Box in a town in California. As per normal procedure, Brinks sent the money to the address, where the employee (or a confederate) picked it up. The employee then disappeared and still remains at large. Subsequent investigation revealed that the bank had never even checked his (phony) previous employment references when he was hired. Boggles the mind, eh? One simple email message! --Peter Golde ------------------------------ Date: 30 Jan 1989 0132-PST (Monday) From: Jeff Makey Subject: Crashing a PDP-11/40 (Computer Folklore) In 1979 or so I heard a story that was already a couple of years old about a DEC PDP-11/40. It seems that one could walk across the room, kick the console terminal, and crash the computer. After a certain amount of wailing and gnashing of teeth, they determined that walking across the room generated a static charge, which was transferred to the console terminal by kicking it. The (now dynamic) charge traveled down the communication wire to the terminal interface board and jumped across a narrow air gap to a neighboring circuit board, thereby disrupting things enough to crash the system. The problem was solved by moving one of the circuit boards to a different slot, which created too large an air gap for the charge to jump. :: Jeff Makey ------------------------------ Date: Mon, 30 Jan 89 14:33:38 PST From: Steve Philipson Subject: Sprint to the Finish? In 8.16 a call went out for documentable stories on computer problems. I'm having one right now with US Sprint. Here's the story. About a year and a half ago I moved from LA to the SF Bay area. I followed the instructions of my long distance carrier, US Sprint, which allowed me to keep my account while I moved, and to have it transferred to my new address when I established a new residence. A problem developed however, as Sprint set up a second account for me at my new address. I started to receive two bills each month, one for my calls placed from home, and another for those placed with the Sprint credit card. The two bills were for different account numbers. I called Sprint about this, and they said they would consolidate the accounts, but I should send checks to pay the ammount due on each. I did so. Here lies the rub. Each time Sprint receives a check from me, they credit only account A. It makes no difference that I place the appropriate account numbers on both checks, and that they are sent in separately with billing forms for the appropriate accounts -- checks for account B get credited to account A. Sprint now has submitted my account B to a debt collection agency. I have repeatedly called customer service and explained the problem, but they have taken no action, even though their records show two checks being credited to account A for each billing period. They have trouble believing that they could be screwing up their accounts receivables so badly. I am now at the point of having my credit history being damaged by US Sprint, and may soon be contacting an attorney to sue them for same. Ah, the joys of dealing with a system where the "computer" makes no mistakes. Note: If any readers out there work for Sprint, I'd appreciate your help in getting this problem fixed. Anyone know the name/address of the CEO? ------------------------------ Date: Sun, 22 Jan 89 22:57 EST From: Stahl@DOCKMASTER.ARPA Subject: Information Security/Computer Crime Statistics The National Center for Computer Crime Data is a non-profit organization devoted to the collection and dissemination of statistical information on computer crime, information security technology, and the information security profession. The Center is currently gathering statistics for its second report, "Commitment to Security." The Report is scheduled for release in May. People with diverse backgrounds will read "Commitment to Security." These include information security professionals, including computer security practitioners, those in the R&D community, and sales and marketing personnel. Prosecutors and others responsible for enforcing computer crime laws will also read the Report. In addition, based on our experience with the first Report, the media will use "Commitment to Security" as a sourcebook on the extent and seriousness of computer crime. Consequently, it is important that the Report be as thorough, valid and meaningful as possible. Towards that end, we have surveyed 3500 computer security professionals and 2500 prosecutors. There are, however, methodological questions about how best to measure and communicate the problems of computer crime and information security technology. Therefore, the Center would like to invite RISKS participants to engage in a conversation on these issues. We would like to have a discussion in RISKS of questions like the following: What statistics would enhance our understanding of the scope and seriousness of the computer crime problem? What statistics would enhance our understanding of information security technology and its potential for reducing computer crime? How can we best get valid statistics on computer crime and computer security technology? How can we best present our information so that it is understood, both by the professional and the layman? We will send a free copy of the report to anyone who meaningfully contributes to the discussion. If you want to talk to us off-line, please call JJ Buck BloomBecker, Director, NCCCD, 213/874-8233 or Stan Stahl Research Director, NCCCD, 213/969-0777 Thanks, in advance, for your participation. [By the way, Dockmaster has been off the net since just after this was posted. PGN] ------------------------------ Date: Sat, 28 Jan 89 0:22:59 EST From: Bernie Cosell Subject: Re: ELIZA and Joe Weizenbaum } > Or, there's the story about the guy who falls asleep in front of his } > terminal with an ELIZA program running and his boss logs on and thinks he's } > talking to him but is actually talking to the program, and gets pissed off. } } This may have actually happened. Joseph Weizenbaum (MIT professor, author of } _Computer Power and Human Reason_) told the anecdote in a class, with himself } as one of the actors. It went something like this -- some of this is } doubtless my own memory inventing things. The dialogue is partially courtesy } of GNU Emacs' Eliza program, and the rest is made up. } } .... anecdote follows... Is that for real, that Joe is telling that story? He has a lot of anecdotes, many of which appear in CP&HR, but I didn't know he was including one like that these days (alhtough such a thing must have SURELY happened some time or other at MIT). The REAL first round of that anecdote dates publicly to a small bit Danny Bobrow wrote in the first issue of some AI journal he started in something like 1968. The thing DID happen, although not quite as the word-of-mouth has transmitted it down to the present generation. The program in question was _DOCTOR_, **NOT** Eliza, and it happened at BBN, not at MIT. I know all of this, because (Ta DAAH!) **I** wrote the original Doctor! Not _Eliza_ --- _doctor_: Weizenbaum's CACM article on Eliza had just appeared and for a variety of reasons I was looking for a neat Lisp hack to play with. The CACM article mostly told me enough, and I went off and wrote the thing. I can supply the details of the *real* "A Turing Test Passed" incident (the title of Danny Bobrow's article describing the event: it involved my version of doctor that I had left running for people to play with to help me get it debugged, the "innocent third party" -- Danny Bobrow, and the Turing Testee, a random executive (whose name I will not reveal) who thought (for reasons that it is hard to figure out) that the Mod-33 was connected through to Danny at home early on a Saturday morning. I can supply more details if anyone really cares, including (if I can dig the thing out of my archives) a copy of Bobrow's article about the incident which included the *real* typescript (danny came in later that Saturday morning and ripped it off of the terminal). Bernie Cosell, BBN Sys & Tech, Cambridge, MA 02238 ------------------------------ Date: Mon, 30 Jan 89 02:26 EST From: KROVETZ@cs.umass.EDU Subject: ELIZA and Joe Weizenbaum Bloom's story about Weizenbaum and ELIZA is close, but the person involved was Daniel Bobrow, not Weizenbaum. The account was described in the December 1968 issue of the SIGART Newsletter, and was reprinted in the book Machines Who Think, by Pamela McCorduck (p. 225). The following is the description of the account: "One Saturday morning about 9 A.M., a BBN Vice-President in charge of selling our Telcomp commercial service arrived at our PDP-1 computer room hoping to be able to use the computer for a demonstration. He found a note on the PDP-1 teletype that read: `TYPE ALL MESSAGES INTO THIS TELETYPE, AND END THEM WITH A PERIOD'. This note was left there by one of the programming bums who had just succeeded in making run a Lisp version of the DOCTOR program (based on ELIZA as developed by Weizenbaum). However, the VP thought that this note indicated that this teletype was linked with the one in my [Bobrow's] home, since I often used the computer all night. Therefore, he started typing to `me', but in fact was typing to this version of the DOCTOR program. The following conversation ensued: VP: Do you think that I can use the computer this morning? TELETYPE: Why do you ask? VP: I might be able to make some additional telcomp sales. TELETYPE: Why aren't you sure? VP: My prospective customers have never seen a demonstration of the system. TELETYPE: Does this mean very much to you? VP: Of course it does. TELETYPE: You seem very positive of that. VP: This is ridiculous. TELETYPE: What do you mean this is ridiculous? VP: Is there any reason why I can't use the computer now? TELETYPE: Tell me more about your prospective customers. VP: Please dial me up on 491-1850 Note that after that remark the VP did not obey instructions and left out the period. Therefore, of course, the computer didn't answer him. This so infuriated the VP, who thought I was playing games with him, that he called me up, woke me from a deep sleep, and said: VP: Why are you being so snotty with me? BOBROW: What do you mean why am I being snotty to you? The VP angrily read the dialog that `we' had been having, and couldn't get any response but laughter from me. It took me a while to convince him it really was the computer". Bob Krovetz krovetz@cs.umass.edu or krovetz@umass.bitnet ------------------------------ Date: Mon, 30 Jan 89 11:50:48 PST From: bobw@ford-wdl44 (Robert Lee Wilson Jr) Subject: Virus conference hosts software swap meet I just received an ad from MIS Training Institure for "Micto/89 -- A Three-Day Conference on Microcomputer technology and its Impact on Security, Control, and Audit." Among its concerns: "Indeed, with the recent front page coverage of the computer virus that struck universities, research, and government organizations across the country, one needn't be a security specialist to be aware of the problem." So what is the first big benefit offered by the conference? " SPECIAL FEATURE Software Bonanza o Software Swap Bring diskettes with your original spreadsheet templates, BASIC, dBase, or other applications and swap them for the brainchild of a coregistrant. MIS will operate a Swap Center throughout the conference where we will maintain a library and make copies of diskettes for participants. o Software Giveaway When you attend the conference you will receive diskettes containing: Lotus 123 macros, utilities, virus detectors, graphics programs, and templates fot data analysis, statistics, investment analysis, and Lotus macros. o Software Directory Along with conference materials, you will receive an invaluable Directory listing over 1000 public domain and shareware programs you can obtain for little or no cost. o MIS Electronic Resource Center MIS' electronic bulletin board containing software programs, bibliographies, articles, audit programs, and much more will be available for your use during the Conference. " The ad says the conference will "update you on new technologies and the risks to which they expose your organization." It sounds as if it might turn out to be a lab course. Bob Wilson ------------------------------ Date: Sat, 28 Jan 89 15:13 EDT From: Charles J. Wertz Buffalo State College Subject: Structured Programs, Project Failures Over the last several months, there have been a number of articles touching on the above in Risks. Most of my computer career has involved the development of business systems for commercial enterprises. I never cease to be amazed by several things. And, I consider them to be contributing factors to the type of problem noted often noted here. They are - . the poor decisions which managers (both business and technical) often make for non technical reasons. . the haphazard approach many of our colleagues take toward requirements determination, requirement verification, and system testing. . the near crimes committed in the name of 'meeting the deadline". . the belief that following the externals of a methodology (such as indenting and naming rules or the format of a deliverable) is the same as understanding and following the methodology. . the failure of many of our colleagues to understand or try to understand the reasoning processes behind the popular methodologies. I'll resist the temptation to go on. I do believe that the above are primary explanations for many of the really poor business systems in existence today. ------------------------------ Date: Mon Jan 23 13:01:30 1989 From: albaugh@dms.UUCP (Mike Albaugh) Subject: Re: Losing Systems (RISKS-8.12) Organization: Atari Games Inc., Milpitas, CA > I would like to suggest that it would suffice anyway if it were applied. The > difficulty is that software is managed by programmers, not engineers. Actually, both are, in my experience, managed by managers, who may not be either, but who owe their primary allegience to other managers. > Programmers have no tradition of quality of their own and insist that their > activity is so different from what engineers do, that engineers have nothing > to teach them. I don't know what the first statement is suppose to mean, but it looks suspiciously like yet another of the gratuitous slaps that programmers typically get from engineers. For the record, I am officially a programmer, but have done a fair amount of hardware design (and been paid well by a satisfied employer for both). The major problem I have found is perhaps the name "software". Managers hear that and assume that changes to software are trivial (and free), while changes in hardware are impossible (or at least very costly.) The result, intended or not, is that programmers are required to add all sorts of software bandaids when the hardware fails to meet its spec. It is seldom actually acknowledged that this is happening, but the lack of acknowledgement does not mean a lack of happening. Especially in a project that involves custom LSI, there will be quite a few "enhancements" snuck into the software spec at the last minute (__way__ past "final" design review) that are nothing more or less than shoving hardware bug-fixes over the wall into the programmer's cubical. > I am hopeful that the use of the term "case" presages the application of more > discipline in programming. I could hope that some sort of documented "requirements control" would make these games more visible, but I doubt it will. They will, as usual, be swept under the rug as "clarification". > I also draw hope from the entreprenurial development of software for the > market, as opposed to works built for hire for a single organization. I saw > a great deal of quality software at Egghead on Saturday. The great advantage an entrepeneurial firm has is that the president, Chief Engineer, and Chief Programmer have lunch together once in a while and can often get away with calling a spade a spade. > William Hugh Murray, Fellow, Information System Security, Ernst & Whinney > 2000 National City Center Cleveland, Ohio 44114 > 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 Mike Albaugh (albaugh@dms.UUCP || {...decwrl!turtlevax!}weitek!dms!albaugh) Atari Games Corp (Arcade Games, no relation to the makers of the ST) 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709 The opinions expressed are my own (Boy, are they ever) ------------------------------ End of RISKS-FORUM Digest 8.18 ************************ -------