Federal officials say that the use of bar codes to identify prescriptions has the potential to cut in half the 7,000 hospital deaths [!] attributed to medication error every year. The Department of Health and Human Services has announced a regulation requiring that drugmakers and blood suppliers add the codes to most of their products within the next two years. HHS Secretary Tommy G. Thompson says, "The pharmaceutical industry wants it, hospitals want it, doctors want it — all we needed was the catalyst to put all it together." [*The Washington Post*, 26 Feb 2004; NewsScan Daily, 26 Feb 2004] http://www.washingtonpost.com/wp-dyn/articles/A6995-2004Feb25.html
You might be interested to read about *Computer Weekly*'s campaign about the recent disastrous attempts by various UK Government. departments to procure large IT systems. CW have submitted evidence to the National Audit Office (UK equivalent of the GAO). See: http://www.computerweekly.com/articles/article.asp?liArticleID=128417&liArticleTypeID=1&liCategoryID=2&liChannelID=28&liFlavourID=1&sSearch=&nPage=1 http://www.computerweekly.com/articles/article.asp?liArticleID=128417 &liArticleTypeID=1&liCategoryID=2&liChannelID=28&liFlavourID=1&sSearch=&nPage=1 The URL is for Tony Collins' front-page article on 17 Feb 2004. For the related articles, just follow the links. Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB +44 (0)20 7040 8422
On 2 Feb 2004, *The New York Times* printed an editorial by William Safire entitled "The Farewell Dossier" describing a CIA campaign in the early 1980s that supplied Russia with deliberately flawed technology; this lead directly to the massive explosion of a Siberian gas pipeline. The CIA became aware that the KGB was purchasing technology on the black market, and endeavored to supply the KGB with technology that would pass inspection, and later fail catastrophically. Two risks leap out at me (trying hard to separate out several moral issues): - I may test for poor design, or poor manufacturing, but these products were designed to pass testing, and then fail. Should I start testing for malicious design (perhaps, if you're building sensitive infrastructure, this is common practice)? - These intentional flaws could 'leak' into the legitimate product lines. Hopefully, these companies had (and still have) good software build processes and code repositories. The article is no longer available at New York Times, but is available: http://seclists.org/lists/isn/2004/Feb/0011.html Safire indicates the story is from a soon-to-be published book: Thomas C. Reed's "At the Abyss".
[Source: Robert Lemos, Flaws threaten VoIP networks, CNET News.com, 13 Jan 2004; PGN-abstracted] http://news.com.com/2100-1002_3-5140284.html?tag=nefd_lede A technical review conducted by the British government has found several security flaws in products that use VoIP and text messaging, including those from Microsoft and Cisco Systems. The flaws affect software and hardware that support the real-time multimedia communications and processing standard, known as the International Telecommunications Union (ITU) H.323 standard. The security problems can cause a product that supports H.323 to crash. For example, in Cisco telecommunications products running its IOS operating system, the vulnerability could be used to cause the devices to freeze or reboot. However, on Microsoft's Internet Security and Acceleration Server 2000, which is included with Small Business Server 2000 and 2003 editions, the vulnerability could allow an attacker to take control of the system.
According to a recent report in the Israeli paper Haaretz <http://www.haaretzdaily.com/hasen/spages/392009.html> the Israel Defense Forces will have to pay tens of millions of shekels to fix a two-year-old automated system for calling up reservists: the system allocates 9 digits for a reservist's cell-phone number, but in a few months all Israeli cell phones will have 10 digits. According to the article, "The army will also look into expanding the fields for personal and other telephone numbers to prevent future problems." Robert Israel, Department of Mathematics, University of British Columbia Vancouver, BC, Canada V6T 1Z2 http://www.math.ubc.ca/~israel
Headline news last week in Germany, as well as in papers with an eye on Europe [1,2,3], has been the failure of the Toll Collect consortium to deliver a toll-collection system for heavy goods vehicles that use the German Autobahn network. (Autobahns are the German equivalent of U.S. freeways.) The system is based on GPS tracking of heavy goods vehicles, using boxes ("On Board Units", OBU) carried in the vehicles. The OBUs contain GPS receivers, and forward their data to a central data installation using European standard GSM mobile telephony. The consortium consists of Deutsche Telekom, Germany's quasi-privatised ex-public telephone operator, DaimlerChrysler, which own 45% each, and France's autoroute toll system operator Cofiroute (a concern of Vinci SA), which has 10%. The consortium has some 24 major subcontractors, amongst whom are such well-known names as HP, Siemens/VDO, Sun, Vodaphone, T-Mobile, Oracle, Peoplesoft, and SAP . In-service date was supposed to be 31 August 2003. There are estimated to be 1.4 million trucks which should pay a toll, of which 400,000 are from other lands. It was planned to deliver 450,000 OBUs by the in-service date; other users were to use static machines at entry points. There were problems with the OBUs, and even five weeks after in-service date only 210,000 had been installed. There were also problems with the bookkeeping software at the data center, which turned out not to have appropriate interoperability with other systems used by truck operators . The contractual arrangements for developing the system were, to someone like me, cause for concern. Although details of the call had been known in essence since August 2001, a call for proposals was issued in April 2002 after a law putting the government's "Anti-Traffic-Jam Program" into force had been passed. The contract was awarded to the consortium on 8th July 2002. The government apparently wanted a twelve-month development schedule. One of the two final bidders said this was "unrealisable"; the winner (Toll Collect, or Electronic Toll Collect as it was then known) proposed an eleven-month development schedule, with a four-month trial period during which the usual contractual penalties for non-performance would be waived. Legal challenges held off starting work in earnest until September 2002. The contract was slated to employ about 350 programmers and 80 SW testers. The development costs are said to lie somewhat over EUR 600M (which is the value of the low-price offer from a Swiss toll-system company, that couldn't provide the necessary insurance and was eliminated early) [4,5]. Talks have taken place between the government and the consortium to establish the rate of compensation for default and how things shall move forward. The talks broke down on 17th February, with the government declaring it would cancel the contract and declaring damages of around EUR 6.5 billion ($8.2 billion) [8,9]. The consortium is already paying EUR 250K/day in fines since December 1, 2003, increasing to EUR 500K/day in March 2004. The government rejected the consortium's offer of EUR 600M per year in compensation . At least one German journal is reporting a week after talks supposedly "broke down" that the fine payment has increased to EUR 1M/day , but that represents only some 60% of the rejected compensation offer, so it is hard to tell what is happening. The consortium says it has "solved software problems causing the delay" . DaimlerChrysler chairman Jürgen Schrempp, one of the most well-known figures in German industry (and maybe in U.S. industry also) says "there is a chance, even with this long delay, to make the system work" . The consortium has offered to deliver a system with reduced functionality by 31 December, 2004, with full functionality implemented a year later . There are lots of figures floating around concerning revenue lost, and costs, and such like. Numbers are seemingly hard-edged things, that bring with them the aura of independence from politics and suchlike. I like to perform arithmetic on such figures to see how they add up. When they don't - and they often don't in this case - one can suspect that they represent negotiating positions rather better than they represent a true accounting. Here are a few, which I recommend treating with caution. The project worth was said to be EUR 7.73 billion, with a service lifetime of 12 years . This figure amounts to ~EUR 54M/month. The government estimates foregone revenue at EUR 156M per month  (derived from EUR 6M per day over a 26-day truck-driving month). Lost revenue from the former "vignette" (sticker) system, which was taken out of service by 31 August 2003, amounts to EUR 30-38M/month. All new road projects and related public-works projects have been put on hold because of the "revenue shortfall" . Some estimate that up to a quarter of transport ministry projects may be cancelled in 2004, putting 70,000 jobs on the line . One major problem appears to be that the government wrote this EUR 156M/month anticipated revenue into its budget already. That is why those road-building projects are on hold and those 70,000 jobs are "endangered". Yes, that's right. Someone let a contract for a complex, highly-distributed system, of a sort which did not exist anywhere before, with a non-trusted, indeed partially non-trustworthy, user group numbering in the millions, that would cost of the order of a billion euros and ~450 technical-person-years to develop, which was to be in full revenue service inside a calendar year from development start date. And then apparently allowed the whole road-construction industry to become dependent on that anticipated revenue, as well as part of the railways. Another major problem appears to be that a consortium containing two giants of German industry signed up to that astonishing contractual schedule. As Andreas Hagen wrote, concerning this so-called Public-Private Partnership (also in German), the contractual politics "didn't do citizens any favors. [It was] badly negotiated, and besides that, the bear's hide was shared out before the bear was shot" [6, my translation]. The contract, by the way, has remained secret, although there is nominally a requirement that it be public. Even the German parliament has not seen it . So few, if any, independent people with the capacity to evaluate them know what the system requirements were or how well they were met. Or, for those interested in the future rather than the past, how close the technology is to meeting them. The contract is so remarkable that few tech-savvies believe that the consortium can have negotiated it in good faith. Some even have a hard time believing that the government negotiated it in good faith, although more are inclined to believe it just didn't know what it was doing. The stories of the negotiations over default bring to mind the game of chicken, in which two drivers drive their cars head-on towards each other at full speed, and the first to swerve loses (everyone cites , but I have just failed to find the example). One sees evidence of the strategy of removing one's steering wheel and visibly throwing it out the car window. But the current case is not a two-player game, nor even a zero-sum game. It is a game of partial coordination, in the terminology of . There is a dealer who owns both cars, employs one of the drivers, and keeps the other in business. He is very concerned about the outcome, and prefers not to lose either of his cars, but is likely to care much less about the drivers. His name is Joe Public. Both sides have an obligation to Joe to fix what is wrong, whether it be technical, contractual or political. It is unlikely to impress Joe over the long term if one of the drivers throws his steering wheel out of the window and then claims the other driver loosened it. It is clear that the risks of the contract were poorly calculated by both sides. The government appears to have believed there was no risk to itself, even though it can hardly seriously have expected DaimlerChrysler and Deutsche Telekom to finance the entire German road construction industry in the event of a default. It stands convicted of bad planning. The consortium members appear to have underestimated the damage to their reputations and consequences for future business that a significant default would entail. There is even a suspicion that they negotiated the original contract knowing, but not adequately conveying, the odds that it could not be fulfilled. At the least, it exhibited either hubris or bad faith, even though we do not know which. As Chairman Schrempp said, "mistakes were made by all sides" . Many technology-savvies have no problem in believing that such a system could be delivered in good working order in three or four years. But for many people including some of my colleagues there now appears to be difficulty in believing anything Toll Collect says on the matter, not necessarily for technical reasons. Oh, yes, a word or two on the technical issues. Putting the blame on "software problems" tells us little. It could have been that the software development process did not measure up to best practice; it could also have been that difficult engineering issues that could not be solved in the hardware were pushed into the software and the software development team didn't know how to solve them either. It could also have been that there were design or specification problems which first manifested themselves, or needed to be solved, in SW. Most likely, it was all three. The Economist says that "important features were left out of the software, such as the ability to work with the payment cards and accounting systems used by most trucking firms. Worse, gremlins charged trucks for being near motorways, rather than on them, or drained batteries while engines were switched off" . German sources give a more specific, longer list of particular problems . It also probably didn't help that the European Union issued a requirement during system development that the design enable the data to be made available to a variety of processing companies, presumably to enable competition in the data-processing phase. In the original design the data would be shared with just one processing company, DaimlerChrysler Services Mobility Management . It seems to me to be premature to sum up. I'll just leave it here, with thanks to Heiko Holtkamp and Jan Hennig, who helped me in finding sources. PBL References  German engineering loses luster, Mark Landler, International Herald Tribune, Friday, February 20th, 2004, http://www.iht.com/articles/130404.html  Berlin kills contract to build satellite-based toll system, International Herald Tribune, Wednesday February 18th, 2004, http://www.iht.com/articles/130098.html  Road rage: European road tolls; Germany's truck tolls crash, The Economist, January 24th-30th, 2004, available for a fee through www.economist.com  Detlef Borchers, Verursachbedingt verspätet, c't No. 22, 2003 (in German), available for a fee through www.heise.de  Joachim Budeck, Dr. Egbert Meyer, Ausgebremste Automatik, c't No. 21, 2002 (in German), available through www.heise.de  Andreas Hagen, Zwischenspiel oder letzter Akt mit Toll Collect? (in German), Telepolis magazine, 25th February 2004, http://www.heise.de/tp/deutsch/special/eco/16827/1.html  Thomas C. Schelling, The Strategy of Conflict, 1960 & 1980, Harvard University Press.  Stolpes Brief an Toll Collect [German Transport Minister Manfred Stolpe's letter to Toll Collect] (in German), 17 February 2004, published by N-TV news channel and CNN Germany, available at http://www.n-tv.de/5215294.html  Der Kündigungsbrief von Manfred Stolpe an Toll Collect [also a copy of Stolpe's letter] (in German), 17 February 2004, published by the Süddeutsche Zeitung, available at http://www.sueddeutsche.de/wirtschaft/artikel/880/26854/ Peter B. Ladkin, University of Bielefeld, http://www.rvs.uni-bielefeld.de
Much of the controversy around SPF <http://spf.pobox.com/> focuses on the "Sender Rewriting Scheme" <http://spf.pobox.com/srs.html>. I don't like SRS either, but I think SPF can be used without it. Maybe I'm wrong, but here's my argument, let's see if anyone can shoot it down. Rationale for SRS: mail that is forwarded with the envelope sender unchanged may appear to violate SPF policy. If we rewrite the envelope sender address at forwarding time, we can change it to something that will conform to SPF policy. Anti-rationale for SRS: since we know where our forwarded mail will come from, we can tell SPF to accept mail from those sites "uncritically". Every forwarder — be it a forwarding address or a mailing list — has an e-mail address associated with it. We can look up the SPF data for that address and extend extra trust to the authorized clients, by letting them send us mail with any envelope sender. What's wrong with this picture? One possible criticism: a forwarding site has a permissive policy, perhaps its SPF record ends with ?all. Solutions: 1. Instead of using SPF to determine your forwarded-mail policy, write your own SPF-style policy and apply that to mail which fails ordinary SPF. 2. Pressure the forwarding site to adopt a more restrictive policy. Another criticism: this gives a lot of trust to the forwarding site(s). The trust could be abused. I have no answer for this except that it's worth it to dump SRS. [MORE From Ben on Wed, 18 Feb 2004 21:22:46 -0500] I realized after I sent you the previous note that there are some points I neglected to address; specifically, more problems with my proposal. o It requires SPF to be configurable on a per-user basis. This will annoy people who want to simply slap SPF into their Internet-facing MTA and forget about it. o It requires explicit end-user configuration, while SRS is theoretically transparent. I still think it's worth considering — SRS is really ugly.
Implementing SPF would do nothing for the people receiving thousands of bounces (myself included). It would simply add another filter that bounced messages back to us because "we" weren't using the right server. What, that wouldn't happen? You'd think not, but then you'd think that the antivirus companies sending us "bounces" would have caught on some time in the past three or so years that the majority of viruses have been forging sender addresses too... The only anti-spam scheme that I have found that works even remotely well is requiring some kind of personally chosen token for every incoming message, along with an accept list (whitelist, greenlight list) for special cases like mailing lists. Anything else, including a standardised challenge-response based system, can be bypassed often enough for spammers to keep trying. The token can be anything, something on the subject line, something added to an e-mail address, an extra header line... just so long as it can't be automated in bulk it's fine. Eventually spammers will catch on and we'll have to come up with a cryptographically secure message signature... but that's for the future. The "notsp" token RISKS uses is a simple example of this scheme. I set up something barely more elaborate for my family months ago and their spam load has almost vanished. As I recall there's been one or two hopeful "419" spammers who read the bounce and actually bothered to negotiate the 'firewall'... over a period of months, down from hundreds of spams (including of course several 419-ers) every day.
E-mail was not designed with spammers in mind, just like the rest of TCP/IP was not designed with 1337 h4x0rz and script-kiddies in mind. We know that slapping a band-aid onto implementation to fix deficiencies in design doesn't work and creates more problems, we've seen it over and over again. Every time I see a proposal like SPF I can't help wondering where its authors have been in the last couple of decades so that they managed to miss this important piece of knowledge. On the other hand, there's no reason to believe anyone will rush to implement new and improved SMTP when/if ever that comes along — nobody's in a hurry to switch to IPv6, are they? > The critics of SPF suggest that spammers would simply find or invent other > addresses to use. Frankly, I don't care about that, so long as they stopped > plastering my personal address on hundreds of thousands of fraudulent and > disreputable spam messages and viruses, and clogging my server's net > connection with vast piles of misdirected bounces. We can do it without breaking anything. We already have directory servers, we already have digital signatures. All we need is a way to query Domain Name Service for directory server of a domain, and a standard directory query-response for an e-mail address and associated public crypto key. Get your domain administrator to publish domain's e-mail addresses and associated public keys on a directory server (BTW, contrary to the popular belief, X.509 was intended for this sort of thing, and not for storing login passwords). Digitally sign your messages. Recipient's mail server then queries directory server to find out if From address is valid, and verifies digital signature to make sure message is signed with key associated with that address. This is as much as SPF will really do, but without breaking SMTP headers, forcing users to send mail via their domain's mail forwarder, etc. — i.e. without any of SPF's obvious problems. Message integrity check using strong crypto is just an added bonus. Apart from technical problems with implementing (large scale, in case of e.g. aol.com domain) PKI (see e.g. http://www.mit-kmi.com/articles.cfm?DocID=385), expect a lot of political resistance to this scheme. It is putting weapons of mass destruction^W^W^W^W crypto software in the hands of Joe A. User -- law-enforcement agencies ain't gonna like that. Commercial certificate authorities won't like it because it effectively makes every sysadmin their own CA. And then there is a whole lot of crypto standards to choose from: ssh, ssl, pgp... And then, here's the real clincher: legislature _wants_ to legalize e-mail spam. Fax spam is illegal because it puts the costs on the recipient: you have to pay for toner and paper. But so does e-mail spam: you have pay your ISP for bandwidth. So if they wanted to ban spam, they'd simply apply existing law to it. Ergo, they don't want to ban spam, and all "anti-spam" legislations are really there to legalize it. Ergo, all you're going to achieve by implementing SPF, blocklists, blacklists, whatever, is to open yourself to lawsuits from "legal" spammers. To get back where I started: we know that technical solutions for non-technical problems don't work. We are clearly dealing with non-technical problem here. Do not expect another Perl wrapper around good old sendmail to fix anything.
According to reports, a break-in occurred at the Israeli Bank Leumi's "Information Fortress". The perpetrators accessed the perimeter physically and proceeded to steal and delete critical client information from the "main server", using a laptop computer they allegedly hooked into the network. You can find an article I put together, with known facts on the story: http://www.math.org.il/leumi-breakin.html. Phone: +972-50-428610 (Cell). http://vapid.reprehensible.net/~ge/Gadi_Evron_Emails.asc
> Bank ATMs Converted to Steal Bank Customer IDs > http://www.utexas.edu/admin/utpd/atm.html Israeli news site Ynet has a story on an ATM theft that has an uncanny resemblance to what's described in the article I am replying to. (In Hebrew: http://www.ynet.co.il/articles/0,7340,L-2877093,00.html) Apparently such a system was installed at a branch of the Israeli Bank HaPo`alim in the city of Ramat Gan, resulting in the theft of 200,000 INS (approximately 44,500 USD). The bank mentioned in its press release that suspicious activity was detected in three other branches of the bank, but no signs of such an ATM theft system was found. Furthermore, since any bank customer can draw money from any bank's ATM, a portion of the customers belonged to other Israeli banks. The Ynet article also mentions that the crime was apparently committed by a Romanian gang.
Please report problems with the web pages to the maintainer