Mark L. Farley, 34, of Lowell, was arrested on 9 Apr 1995. Working as an orthopedic technician in the Newton-Wellesley Hospital, he allegedly accessed a former employee's computer account to search through 954 confidential files of patients (mostly young females) for telephone numbers, which he then used to make obscene calls. (He had pleaded guilty in 1984 to raping an eight-year-old girl in Erving.) He is apparently the first person to be charged under a new Massachusetts statute that makes it a criminal offense to use someone else's password to gain access to a computer system. He is also accused of stealing hospital trade secrets, and making obscene or annoying telephone calls — apparently from the hospital. [Source: Hospital Worker Charged under New Massachusetts Password Law By MATTHEW BRELIS, *The Boston Globe*, 12 Apr 1995.] [Health-care records are increasingly the subject of privacy concerns, because of their rampant abuse. This case has caused quite a stir in the Boston area. PGN]
I just received this peach from a friend at a local multi-million dollar computer company (after their phone was busy all day). They recently had some layoffs, but frankly it sounds like their problems started long before that: > My phone isn't really busy. There's a little problem at ******* today. > They were doing some facilities work in one of the labs and > accidentally set off the earthquake detector. Since earthquakes tend to > set off the indoor sprinkler system, the earthquake detectors shut off > electrical. This lab happened to share some wiring with the phone system, > and nobody knows how to reset it. This is one of those little gaps that > got left with the layoff. The Risks of not having detailed instructions for disaster recovery are apparent. The question of why a lab is sharing power with the main phone system is a sub-Risk left for the student. While I'm at it, just why would you design an earthquake detection system that didn't require two or more significantly separated points for verification? Local shocks from people dropping heavy objects are relatively common... -Tim Kolar cisco Systems
You've heard of Fly-by-Wire? well what about Fugue-By-Wire! The UK New Scientist magazine, 15 April 1995, reports that Notre Dame's organ is not suitable for concerts following a two year restoration costing =A31.3 million (Pounds Sterling) in which six computers were installed to relay the organist's instructions from the manuals (keyboards) and pedals to the organ pipes. The cathedral's administrator has cancelled all concerts as a series of malfunctions, including `memory failure', has caused the organ (as he is reported as saying) `to suddenly stop working. It takes five to ten minutes to get it going again. This is too stressful for the organists who never know when it will happen'! It is still used for Mass, however, as when it `crashes' a small organ fills in the unintented silence. JS Bach should have been warned that his `Toccata & Fugue in D Minor' would be too `memory intensive' for organs of the future! James@prognote.demon.co.uk Program Notes Limited
Eleven Electronic Bulletin Board Systems Dismantled (From A Royal Canadian Mounted Police news release) Montreal, April 12, 1995 - Seventeen searches conducted in the Greater Montreal area by the Copyright Investigations Unit of the Montreal RCMP Federal Enforcement Section put an end to the operation of eleven electronic bulletin board systems (BBS). Since 6 o'clock this morning, 75 RCMP members have been dismantling bulletin boards specialized in circulating copyrighted Canadian software such as Le Correcteur 101, CorelDraw, Winfax PRO, as well as products developed by Audodes [Autodesk?], Borland, Clark Development, DataStorm, Disney, IBM, Lotus, Microsoft, Windows 95, Mustang Software, Novell, Playboy, Quarterdeck, Sierra, Symantec and many other firms. Computers and peripherals worth more than one hundred thousand dollars were seized, along with millions of dollars of pirated software. This is the most important operation of this kind yet in Canada against illicit bulletin board systems. About 15 persons will appear in court at a later date to face charges under the Copyright Act which sets out severe penalties for offenders: - 6 months and/or $25,000.00 per count for summary conviction offenses; - 2 years and/or $1,000,000.00 per count for indictable offenses. .... [invitation to press conference 95.04.11].... - 30 - Resource person: Sergeant Serge Corriveau Federal Enforcement Section Tel. (514) 939-8307 or Constable Gilles Deziel Community Relations Section Tel. (514) 939-8308 ----- _La Presse_, the largest newspaper in the greater Montreal area, published a news story about the raids on 13 Apr 1995 (translation and summary by MK): Major Strike by the RCMP in the InfoBahn [Gros coup de la GRC dans l'inforoute] by Eric Trottier, La Presse The RCMP has decided to do a little house-cleaning in the joyously anarchic world of the electronic highway. Thanks to a computer-science infiltration operation, the federal police yesterday dismantled 11 bulletin boards that were trafficking in tens of thousands of software packages around the world. "It's the first time we have been able to implement this type of penetration of BBSs. Even in the U.S., the most important dragnet of this type has so far only allowed the dismantling of six BBSs at a time," said Sergeant Serge Corriveau to La Presse shortly after the investigators completed more than a dozen penetrations and seized more than C$200,000 [U$140,000] of computer equipment. Key points from the article: o News of the raid spread rapidly through the Internet; o The 11 BBSs were involved in large-scale fraud in N.America and Europe. Subscription fees of C$30-C$50 per month allowed participants to download copies of proprietary software at will. o "Everything available legally on the market was offered by these BBSs," said Sgt Corriveau. o Some of the more audacious BBSs offered beta copies of Windows95. o There are about 700 BBSs in the greater Montreal area; the RCMP estimate that three-quarters of them traffic in stolen software. o Some of the BBS have become virtual flea markets of pornography, bomb-making instructions, and details of how to succeed at suicide. o In one of the shut-down systems, stolen goods and illegal assault weapons were advertised for sale. o It has taken a year to infiltrate the BBSs; some officers had to wait up to four months to gain entrance to the inner areas of the boards they were investigating. o The raids involved 75 officers in Montreal, Outremont, Repentigny, Longueuil, Saint-Amable, and the St-Jerome area. o The BBSs shut down are: Notice, Twins, Red Alert, Perfect Crime, Beyond Corruption, Line-Up, Wolf Pack, On the World, Restricted Area and Necromancer Mecon. o Most had about 6 telephone lines for full-time access, serving 100-250 clients, with some in Europe. The larges, Notice, had 350 clients who each paid $50/month, for an untaxed revenue of C$210,000 per year. o The police estimate that 11 to 15 criminal hackers will be indicted as a result of the raids. They each face fines of C$25,000 to C$100,000. M.E.Kabay,Ph.D., Mgmt Consultant, LGS Group Inc. (Montreal, QC); Director of Education, Natl Computer Security Assn (Carlisle, PA)
>The RISK — don't forget today's news is tomorrow's history. While >Microsoft might have been trying to be helpful in 1992, they forgot that >someone just might use it in 1995. All very irritating! --------------------------------- Of course not. Everyone would have switched to Win 95 by then... Maybe there is a RISK here. Suppose a software developer finds problems in some current version of a program, but instead of sending out an immediate bug-fix (with all its attendant negative publicity), elects to wait until the next major version release before including the fixes. If this release is then delayed, are users then left using broken software for longer than is necessary? Ted Wong, Computer Science, Cornell University <email@example.com>
>Could it be that the visual and mental concentration required to >operate a computer can constitute a potentially fatal distraction >for a police officer? Depends on the situation. It would be foolish to begin using the computer when you knew you were in a tactical situation that demanded keen awareness of your surroundings. However, a cop who spent his entire shift worrying about being ambushed by someone with a high-powered rifle would, I should imagine, have a brief, ineffective, possibly even dangerous career en route to a psych disability. But perhaps there is a risk, related to the way a computer sucks your attention into a black hole where space and time have little meaning. A cop who pulls over into some secluded area to finish up his paperwork might well face a less absorbing task that lets him monitor what's going on outside the car. There's a RISK much more probable than getting ambushed, though. I became aware of it while watching "Cops" on the bread-and-circuses dispenser one night. Our hero was driving along a city street at a pretty good clip while in a complete heads-down mode, using the computer. Had there been a bicycle or baby buggy in front of the car, the screeching noise from underneath the axle would've been his first clue that something was wrong. --Joe
The story relating to the murder of an Oakland Cop, who was slain while using in car-computer, brings another "interesting" RISK to mind. Since the cop was murdered while using the computer, it is safe to assume that the cop was properly signed into the system, when he died. The criminal could have used the computer to access police files, perhaps alter them, or otherwise infiltrate the system and violate the integrity of the computer system. Matthew Raffel Interactive Software Development, Inc. firstname.lastname@example.org
In response to Erik Kraft's message about the lack of power inherent to many "user friendly" interfaces: This sort of thing happens quite frequently; it's one of the reasons why I won't touch Window & Mac machines, while I love UNIX. The typical problem is that it's much easier to implement a "computerese" interface (which requires little design) than to design & implement a worthwhile user-friendly interface *that has the same flexibility*. The risks? Building software upon software that doesn't allow complete flexibility! Eventually *something* is going to break, and if low-level and flexible configuration/command ability isn't available, the only person who's going to be able to fix it will be the original programmer. Perhaps some advice: build the graphics interface to critical utilities on TOP of a flexible command-line system, not concurrent with it. [obRisks: since I don't deal with inflexible user interfaces any more, I don't have any recent examples of this sort of thing. The most relevant one I can think of is the (old?) NeXTStep graphical system manager interface. Once I deleted the NetInfo database, and (after browsing the manual pages in single user mode for several hours) had to reinstall the entire system. It's virtually impossible to change the system using the command-line utilities. ] Titus Brown, email@example.com.
Erik Kraft responds to my comment about the advantage of "human search" of available computer search techniques in finding a book in a library listing by describing a similar problem he had, which he was able to solve by talking to a friend at the computer center and gaining access to the "computerese" interface. Curiously, when I first described my problem to a friend who uses the same library, he pointed out that the programs involved provided two interfaces: The "easy to use" hierarchical menu system meant for customers, and the higher-powered system meant for librarians. The particular search I needed could, indeed, have been done fairly easily from a librarian's terminal. But this illustrates another aspect of the same risk. Most people don't have friends at the computer center, or even know librarians who will let them use the "privileged" interface. The only interface available to them is the "public" interface, which in the interest of ease-of-use by a population who have no reason, time, or desire to "learn about this fancy computer stuff", has been deliberately limited in its capabilities. I recall a discussion I had a number of years back with Alan Perlis. (Alan was a wonderful person with a very broad range of interest and insights, so this isn't as odd as it will sound.) I had just been trying to buy a wood trash can. I couldn't find any - just cheap metal and cheap molded plastic "fake wood". I commented that technological advances sometimes lowered the quality of the products one could find. Alan's response was that, no, I was looking at it wrong. Pre-technology, most people could only afford to buy low-quality versions of a product; the reasonably well off could buy higher-quality versions. Technology - particularly automation - made it possible to raise the quality of the cheap stuff. This eliminated both the older forms of the product: The real junk was no cheaper to produce than the better post-technology product so couldn't compete; and the former "reasonable quality" was now much more expensive, and only a bit better. Often, a new "super-high-quality" stratum came into being as well - where "quality" often really means "snob appeal" - but at much, much higher prices. (Sometimes this already existed and simply continued; sometimes not). For the relatively less well off, technology provides better products for equal or less cost. For the very well off, it makes little difference. But there is a range in the middle who actually lose ground. We are seeing a similar effect in these library interfaces. For the vast majority of people, who rarely use the library systems and have no need to do anything sophisticated when they *do* use them, they are a clear step forward. Those people who are "wealthy" by virtue of having special access and knowledge at worst break even, and often gain. But there are those in the middle for whom the new technologies are a step backward. Library systems are not alone - those of us who, for example, are used to writing command files or shell scripts to accomplish sophisticated things find GUI interfaces frustrating. More and more systems are "sealed" - at least Mr. Kraft's friend in the library computer center could give him access to a low-level interface. What happens when the only access is through a Web server that no one can log onto? You get the services it chooses to give you, period. -- Jerry
I've long been a bit disturbed by the trend toward distributing software without documentation, instead referring the user to online documentation at a WWW site. Here is an example of how this arrangement can go wrong: Forwarded message: > From: firstname.lastname@example.org (Elizabeth Frank) > Date: Tue, 18 Apr 1995 12:54:42 -0500 > To: email@example.com > Subject: re:ncsa security problems > > A new version of 1.3 with several security patches was > released last week. (version httpd_1.3R+ on our ftp server, > ftp://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd) > > Unfortunately, hoohoo.ncsa.uiuc.edu (where our documentation > is located) was hit by lighting and will not be back in > service for a couple of days. This only affects our documentation, > the patched code is on the ftp server which is still working. Note that there is a mirror of the NCSA documentation at http://www.vtls.com/docs/, but it is not clear that either VTLS or NCSA have made a commitment to keep the mirror up to date (nothing at the VTLS site mentions version httpd_1.3R+). This highlights another risk of online documentation: without a careful versioning scheme, it is easy to find oneself fetching documentation for a different version of the software than the code at hand. -- Prentiss Riddle firstname.lastname@example.org -- Systems Programmer and RiceInfo Administrator, Rice University
Cliff Stoll makes an excellent critique of online catalogs in his new book _Silicon Snake Oil_. He enumerates many of the criticisms that contributors to RISKS have discussed. I recently ran into a problem with the online catalog for the library where I work. Asking to see the card catalog, I was told that it was 2-3 years out of date. The online catalog that replaced it accessed classified information and was therefore unavailable for general use. The librarian had to perform the search for me. Since I was looking for a specific book, it was not a problem. On the other hand, if I was doing more general research, I would have been stymied. Doug Shapter email@example.com | firstname.lastname@example.org
People seem upset by the use of a computer to control an electric chair. While I agree that electrocution is horrifying, nobody has identified the computer-related risk. The claimed "risk" seems to be that computers and other electronic devices are being used to kill. But how do the inventors of those gadgets feel about the fruits of their labor being used by military forces? The obvious actual risk is that the computer might make more mistakes than human executioners, or might make worse ones. But the human executioners apparently already have a record of botched executions, so a proper assessment would have to weigh the risks on both sides. Of course a better solution might be to do away with electrocutions altogether, but that debate doesn't concern the use of computers. -- David A. Karr (email@example.com)
* CALL FOR PARTICIPATION * * 4th Conference on Software Risk * * Theme: Current Successes and Future Directions * * November 6-8, 1995 * * Monterey, California * You are invited to participate in the 4th SEI Conference on Software Risk, November 6-8, 1995, in Monterey, Calif. The conference will include plenary sessions, formal presentations, invited panel discussions, birds-of-a-feather (BOF) meetings, and SEI Risk Program tutorials. Vendor exhibits will also be offered. * Theme * The theme of the conference is Current Successes and Future Directions. Significant progress in the development and application of software risk management techniques by government agencies, contractors, and vendors has occurred since the 3rd SEI Conference on Software Risk. We ask you to share your field experiences, results, and lessons learned from using and applying these techniques. We request presentations and BOF topics that include: * Applying Technical Performance Measurement to risk management * Measuring the return on investment in risk management: quality or cost * Making informed decisions in conditions of uncertainty * Learning from sharing risks across domains * Adapting existing risk management methods to your organizational culture * Managing people: risk takers and risk avoiders * Managing the risks of using COTS * Participation options * Presentations - individuals or teams interested in making a 45-minute presentation (including questions and discussions) must submit a 2000 to 3000 word abstract and a brief biography. Abstracts must describe, not just list, the topics covered. Preference will be given to submissions that demonstrate results of the application of risk management in software development projects. Birds-of-a-feather - individuals or teams interested in conducting a two-hour BOF discussion Tuesday evening must submit a description (including an outline of the topics covered) and a brief biography. Exhibitions - organizations or individuals interested in exhibiting their risk-related products and services or experimental tools must contact Carol Ulrich for more information. * Important dates * June 23, 1995 Extended abstracts and BOF descriptions due July 17, 1995 All accepted presenters have been notified September 11, 1995 Camera-ready copy of final abstract, slides, and BOF materials due * Benefits to participants * Individual presenters or presentation teams are entitled to one waived registration fee. Birds-of-a-feather leaders will be provided with a classroom setting; the SEI will reproduce materials for attendees. Exhibitors may have the opportunity to present a 10-minute overview of their risk-related products and services or tools to the conference attendees prior to the exhibit. * Send submissions to: * Carol Ulrich, Conference Chair, Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA 15213 Phone 412 / 268-3624 FAX 412 / 268-5758 Internet firstname.lastname@example.org [Lorrie Orndoff, Administrative Assistant, Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA 15213 Phone 412 / 268-3098 FAX 412 / 268-5758 Internet email@example.com] * Program committee * Barry Boehm, USC Center for Software Engineering Robert Charette, ITABHI Corporation Richard Fairley, Software Engineering Management Associates, Inc. Yacov Haimes, University of Virginia Center for Risk Management of Engineering Systems Ronald Higuera, SEI Richard Murphy, Deputy Chair, SEI John Salasin, ARPA Carol Ulrich, Conference Chair, SEI The SEI is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University.
Please report problems with the web pages to the maintainer