The lead item in this week's Talk of the Town (New Yorker, 16 Mar 1992, pp.31-32) is a letter reporting on NASA's plan to abandon the Magellan spacecraft (which is scientifically an enormous success and which is continuing to produce remarkable results, far beyond original expectations), in order to save a few million dollars. The letter makes a very compelling case for the incremental benefits of keeping the mission going, and concludes thusly: Given the cost of building Magellan and getting it to Venus — about half a billion dollars — most of the NASA scientists think that to turn it off prematurely is penny-wise and pound-foolish. It is the loss of a kingdom -- more than that, of a planet — for want of a nail.
E-470 hits new detour (Mary George, Denver Post Environment Writer, Denver Post, 13 Mar 1992, Page 2B The E-470 Public Highway Authority clocked another delay in its race to the new Denver Airport yesterday when the company that wants to finish the $1 billion tollway revealed it's having computer troubles. A computer model, which seeks to forecast traffic and toll revenues, isn't yet accurate enough to satisfy state transportation officials considering a $100 million loan for the highway, or financiers who would help bankroll 31 miles of four-lane construction, said Ed Gorman, chief executive officer of Morrison Knudsen, the company seeking to build the road. The revenue forecasts and financial plans now have been delayed since February. The delay is costing the company about $250,000 a month. [The rest of the article is about high finance, except for this last sentence:] About 3,275 drivers used the existing E-470 segment daily last month, not enough to pay for tollway operations. [What I found interesting about this story was that the company was thwarted not because its model didn't produce the result that the financial backers wanted, but because they didn't trust the result. (At least, that's the implication of the article; perhaps the model was declared "inaccurate" simply because it doesn't forecast enough revenue.) Are public officials and financiers finally realizing that just because a computer model says something doesn't mean that it is so? -Jeff Mogul] [P.S.: By the way, if they charged each of those 3275 drivers $2 each day, it would take 418 years to pay back the $1 billion construction cost (excluding several quintillion dollars of interest expense). JM]
This morning, while on my way to deliver my 19 month old son to the babysitter, the railroad crossing gate closed. It opened shortly after that, with no train having passed. Now, this sounds like a completely benign failure mode, yes? Not if you have a 19 month old who LOVES trains in the car! Joshua sure got upset when no train followed the gate's closing... Alan M. Marcum, NeXT Technical Support amm@NeXT.COM
An increasing number of software manufacturers are encountering problems with viral infections of their products. It is interesting that in an environment where manufacturers and users are becoming more cautious, that the installation procedure for Microsoft Word 5.0 includes directions to remove any virus protection from your system before proceeding with the installation. W.M. Buckley - Applications Systems Division - LLNL (510)423-4581 firstname.lastname@example.org
On page 23 of the latest [April 1992] issue of Scientific American is a two-page spread from Microsoft touting their "Word for Windows" product, including a tag pointing out how easy it is to print envelopes: "Easy. We mean REAL easy. There's an envelope command right on the screen that addresses and prints automatically." And indeed, the envelope shown resting on top of the sample letter in the photo is nicely addressed, with the printing all lined up and centered. But the address on the letter and the envelope differ - some of the digits in the Zip Code got scrambled between the address on the letter and the address on the envelope. [And neither Zip Code is proper for San Diego, which is the city shown in the address. One is in Los Angeles, and I think the other is much further north.] What's the Risk? Financial. If you're going to advertise a feature, you should at least make it look like it works. One can't help but wonder how much such an error affects sales. - Brian
In RISKS 13.28 Brian Randell reported a series of bank ATM robberies involving forged magstripe cards. On page B3 of the 17 March '92 Los Angeles Times an article by Hugo Martin headlined "Security Upgraded At Airport" reports that Burbank airport (one of L.A.'s smaller airports) will install an $83,000 electronic locking system to meet FAA requirements for more stringent control of access to non-public areas. The system will replace current key and combination locks. Airport employees will get badges with magstripes. Doors will be unlocked by a computer when authorized personnel swipe their cards through readers adjacent to the doors. The system will allow for giving or revoking authorization on short notice, and for conditioning authorization on time of day (or week, etc). "The new system also records each employee's use of a door, allowing airport officials to determine which employees were present in a secured area at a given time." Risks? The usual from (IMHO) insufficiently thought-out systems. The system will not, in fact, provide a good record of which people were in a secured area at a given time, because the doors aren't being changed and people can pass through them without authorization or recordation when they're opened by other people. Also, it's easy to duplicate the magstripes on the cards. A photo with the story suggests that a combination (passcode) could be required along with the card (it shows a card reader with a keypad) but the story doesn't mention if this is done. Mark Seecof Publishing Systems Department, Los Angeles Times
Statement of Observations concerning the Information Technology Security Evaluation Criteria (ITSEC) V1.2 The Information Technology Security Evaluation Criteria (ITSEC) are the result of an initiative driven by the Commission of the European Communities. Their current version 1.2 from June 1991 is the basis for the evaluation of secure IT systems in the EC member countries for at least until 1993. Although the ITSEC are quite advanced compared to the TCSEC (Orange Book) and there have been discussions on V1.0 and V1.1, a lot of several critical points remained in V1.2, especially aspects of possible functionalities and assurance methods. Therefore the Data Protection and Data Security Task Force of the German Society for Informatics (GI) decided to issue and publish a "Statement of observations concerning the ITSEC V1.2". Observations, criticism and proposals concentrate on the following issues: (1) Title and Scope of ITSEC (2) Functionality (3) Assurance - Effectiveness (4) Assurance - Correctness (5) Post-Evaluation Problems (6) Development and Discussion of the ITSEC The full text has been posted to alt.security, misc.security and comp.security. Kai Rannenberg Technische Universitaet Berlin Informatics Department Sekretariat FR 5-10, Franklinstr. 28/29, D-W-1000 Berlin 10, Germany email@example.com Phone: (+49 30) 314-73499 Fax: (+49 30) 314-24891 [It is also available for anonymous FTP from CRVAX.SRI.COM with RISKS-13.ITSEC as its file name. Important for security- minded folks. The ITSEC is good stuff. PGN]
From the 17 March 1992 _Rocky Mountain News_: Hacker ordered to get mental help (Reuter) A computer hacker who pleaded guilty Monday to breaking into NASA computer systems as ordered to undergo mental health treatment and not use computers without permission from a probation officer. Richard Wittman, 24, of Lakewood [Colorado] was sentenced to three years probation by Denver U.S. Distrcit Judge Sherman Finesilver in a rare prosecution for breaking into a computer system. Wittman pleaded guilty last fall to one count of breaking into a National Aeronautics and Space Administration computer. Prosecutors said Wittman had spent four years trying to get into computer systems. In a plea bargain, Wittman admitted gaining access to NASA's computer via a malfunction in a bulletin board service.
The following couple of articles were sent to the ISDN discussion list. I have briefly commented at the end. (very briefly) OCL. ============================== Date: Tue, 10 Mar 92 09:32:56 PST From: heath@com.CMC (Frank Heath) Subject: Wiretapping and ISDN Sender: isdn-request%com.Prime.List@com.Prime.Relay From the LA Times Saturday, March 7,1992 FBI Fear Phone Advances Will Hamper Wiretapping Washington- The FBI, contending that rapidly developing telecommunications technology is hampering the vital tool of wiretapping, proposed legislation Friday that would require the industry to ensure that improvements do not interfere with the ability to secretly record conversations. It also proposed that consumers pick up the cost of changing current wiretapping equipment to keep pace with new technology. If the problem is not solved, "terrorists, violent criminals, kidnapers, drug cartels and other criminal organizations will be able to carry out their illegal activities using the telecommunications system without detection." FBI Director William S. Sessions said. [...] At issue is the rapid move toward digital telephone communications and fiber-optic systems in which thousands of conversations can be carried by filaments roughly the size of a strand of human hair. William A. Bayse, assistant FBI director for technical services, and other FBI officals contend that the transmission of hundreds and sometimes thousands of digital conversations over a single link prevents current wiretapping technology from isolating conversations for recording as required under the 1968 federal wiretap law. [...] Other FBI offical said the expense could be passed on to telephone users at a cost of "probably less than 20 cents an average per month." [...] FBI officals maintained, however, that they already have encountered difficulties in recording digitally transmitted conversations, now used by about 10% of the nations phones. They declined, however, to give any examples of such difficulties. [Well folks, we may have finally discovered the long awaited "Killer ISDN Application", drug dealing! ;-) On a more serious note is the FBI's technology that broken, that it can't deal with multiplexed transmission? You would think the NSA has sufficent technology to do it. I don't know of ISDN phones that come with built in scramblers, although it would be pretty easy to do. I don't think this is what they are talking about here. Particulairly galling is we are all going to be changed 20 cents a month to support big brother type intursions. This sort of legislation can't help but to slow ISDN's already glacial deployment. For the ASI types what we need now is a new session block, Circuit Switched Voice, Secure(except where prohibited by law). Frank S. Heath, CMC.COM My views not CMC's or Rockwell's. ] [And here is a followup article - OCL] Date: Tue, 10 Mar 92 17:54:13 +0000 From: I.Wakeman@uk.ac.ucl.cs Sender: isdn-request <firstname.lastname@example.org> I find it strange that the FBI should be tapping into lines directly (I saw an old Cagney and Lacey last night which had them sitting in a basement with a breakout box and a tape-recorder - definitive proof of the obsolescence of US police equipement). Here in the UK, there is this persistent rumour that our digital exchange has the most advance security facilities in the world, allowing tapping of a conversation at the switch rather than on the wire. This means our police don't have to get their hands dirty, assuming that the Home Secretary gives permission, and all they need to do is attach a tape-recorder (or tape drive) to a port at the exchange. Does this mean we can expect the sales of System X to take off in the US, as long as the FBI give their backing? Or are the FBI forbidden to attach to the switch? cheers, ian [One of the forthcoming set of RISKS related to future telecommunication systems. I'm currently working on Broadband ISDN, and believe me, when that will be implemented, I doubt that the FBI will even bother about monitoring lines due to the excess amount of information being transmitted. Olivier M.J. Crepin-Leblond, Imperial College London, UK.]
The recent thread on ISDN and bugging reminded me of an interesting issue. Some years ago I worked in Ericsson's effort on designing ISDN phones. One of the features we implemented was that in order to faciliate testing, the exchange could send signals to set up loops in the terminals (this is fairly standard) and to leave an "open end" in case deeper testing was ever needed, a mechanism for reading or writing any data address on the terminals internal system bus was provided. In theory, a piece of code could then be added byte by byte to the RAM of the terminal and a patch jump applied to link it in. Not that I think anybody would be foolhardy enough to actually do it, but in theory it would be possible. But one morning in a coffee-break brainstorm-session we started speculating on what COULD be done if a feature like this were abused (say, by the FBI) and we realized that since all the control ports of the phone were regular bus devices, anybody who knew the address to the proper latch (easy to read if you got hold of the system description documents), could send the instructions to activate the microphone and connect it to a B-channel without going through all the layer-3 protocol stuff or the phone's internal program. Just a couple of "POKE"s and presto, the room is bugged. This would be more devious than the "normal" kind of bugging where a line is tapped, since it would take place when there's no phone call going on. So as a collective act of civil disobedience the HW and SW designers got together and put in an extra HW "AND" gate in a strategic location so that the bitstream from the codec to the S-interface was choked unless either the receiver was (hardware) off-hook or the "hands-free" indicator LED was turned on. This meant that the SW had to set two latches to connect the phone to the line but, hey, that's what macros are for... At least, if anybody were to try and turn the phone on for bugging purposes, they would have to turn on the LED on the front. Hopefully this would be conspicious enough to alert anybody in the room. Of course, this didn't prevent bugging of a phone call, but that's impossible to guard from without encryptation anyway. ALL exchanges have supervision devices that can be (ab)used to listen in on conversations. Telecom manufacturers selling to certain countries routinely get orders for far more supervision equipment than would normally be needed. Why is not too hard to guess. The upshot of this is that when I read the discussions about FBI's fear of new technology, I remembered what we did to deliberately prevent something akin to what they want legislation to force designers to give them. Does this mean that I'm now "Persona Non Grata" in the US? :-) Any others out there who can think of similar "features" of the new digital technologies? Are we (the guys who then worked at Ellemtel) the only ones to have thought of it and tried to prevent it? Are there any others on the list/net who have worked in the field and have stories to share? Torsten Lif Ericsson Telecom AB, EO/ETX/TX/ZD S-126 25 STOCKHOLM, SWEDEN Phone: +46 8 719 4881
Call For Participation INTERNATIONAL WORKSHOP ON FEATURE INTERACTIONS IN TELECOMMUNICATIONS SOFTWARE SYSTEMS St. Petersburg, Florida, USA, December 3-4, 1992 DESCRIPTION This workshop is planned to encourage researchers from a variety of computer science specialties (software engineering, protocol engineering, distributed artificial intelligence, formal techniques, and distributed systems, among others) to apply their techniques to the feature interaction problem that arises in building telecommunications software systems. The feature interaction problem has been a major obstacle to the rapid deployment of new telephone services. Telecommunications software is huge, real-time, and distributed; adding new features to a telecommunication system, like adding new functionalities to any large software system, can be very difficult. Each new feature may interact with many existing features, causing customer annoyance or total system breakdown. Traditionally, interactions were detected and resolved on a feature by feature basis by experts who are knowledgeable on all existing features. As the number of features grows to satisfy diverse needs of customers, managing feature interactions in a single administrative domain is approaching incomprehensible complexity. In a future marketplace where features deployed in the network may be developed by different operating companies and their associated vendors, the traditional approach is no longer feasible. How to detect, resolve, or even prevent the occurrence of feature interactions in an open network becomes an important research issue. The feature interaction problem is not unique to telecommunications software; similar problems are encountered in any long-lived software system that requires frequent changes and additions to its functionality. Techniques in many related areas appear to be applicable to the management of feature interactions. Software methodologies for extensibility and compatibility, for example, could be useful for providing a structured design that can prevent many feature interactions from occurring. Formal specification, verification, and testing techniques, being widely used in protocol engineering and software engineering, contribute a lot to the detection of interactions. Several causes of the problem, such as aliasing, timing, and the distribution of software components, are similar to issues in distributed systems. Cooperative problem solving, a promising approach for resolving interactions at run time, resembles distributed planning and resolution of conflicting subgoals among multiple agents in the area of distributed artificial intelligence. This workshop aims to provide an opportunity for participants to share ideas and experiences in their respective fields, and to apply their expertise to the feature interaction problem. We welcome papers on preventing, detecting, and/or resolving feature interactions using either analytical or structural approaches. Submissions are encouraged in (but are not limited to) the following topic areas: - Classification of feature interactions. - Modelling, reasoning, and testing techniques for detecting feature interactions. - Software platforms and architectures for preventing or resolving feature interactions. - Tools and methodologies for promoting software compatibility and extensibility. - Environments and automated tools for related problems in other software systems. FORMAT We hope to promote a dialogue among researchers in various related areas, as well as the designers and builders of telecommunications software. To this end, the workshop will have sessions for paper presentations, including relatively long discussion periods. Panel discussions and a short tutorial on issues in the feature interaction problem are being organized. ATTENDANCE Workshop attendance will be limited to 75 people. Attendance will be by invitation only. Prospective attendees are asked to submit either a paper (maximum 5000 words) or a single page description of their interests and how they relate to the workshop. About 16--20 of the attendees will be asked to present talks. We will strive for an equal mix of theoretical results and practical experiences. A set of working notes will be provided at the workshop. Papers with the highest quality will be considered for publication in a special issue or section of a research journal. SUBMISSIONS Please send five copies of your full original paper or interest description to: Nancy Griffeth Bellcore, MRE 2L-237 445 South Street Morristown, NJ 07962-1910, USA E-mail: email@example.com Tel: (201) 829-4538 Fax: (201) 829-5889 IMPORTANT DATES 1 June 1992: Submission of contributions. 1 August 1992: Notification of acceptance. 15 September 1992: Submission of camera-ready versions. WORKSHOP CO-CHAIRPERSONS Nancy Griffeth (Bellcore, USA) Yow-Jian Lin (Bellcore, USA) PROGRAM COMMITTEE chair: Hugo Velthuijsen (PTT, The Netherlands) E. Jane Cameron (Bellcore, USA) Steven Harris (BNR, Canada) Gerard J. Holzmann (AT&T Bell Laboratories, USA) Michael Huhns (MCC, USA) Luigi Logrippo (University of Ottawa, Canada) Harm Mulder (PTT, The Netherlands) Jan-Olof Nordenstam (ELLEMTEL, Sweden) David Notkin (University of Washington, USA) Akihiro Shimizu (NTT, Japan) Yasushi Wakahara (KDD R&D Laboratories, Japan) Pamela Zave (AT&T Bell Laboratories, USA)
Please report problems with the web pages to the maintainer