Charles Perrow, The Next Catastrophe: Reducing Our Vulnerabilities to Natural, Industrial, and Terrorist Disasters Princeton University Press, 2007, viii+377 Charles Perrow's earlier book, Normal Accidents: Living with High-Risk Technologies (Basic Books, New York, 1984), was an enormously important inspiration for many early RISKS readers. His latest book is likely to be even more important, and certainly very timely. From the jacket: This book is "a penetrating reassessment of the very real dangers we face today and what we must do to confront them." On a personal note, when I called him out of the blue in the late 1980s and asked him if he would keynote one of the COMPASS conferences (predecessors to the ACM ACSAC conferences), he demurred -- saying he was not a computer expert. And yet his message was completely on the mark for that audience and for RISKS back then. Twenty years later, there is no question that his writing is absolutely relevant to the huge set of technological and social problems we face today. The message of his new book is very clear: we must do much more to reduce the vulnerabilities across the board. "Rather than laying exclusive emphasis on protecting targets, we should reduce their size to minimize damage and diminish their attractiveness to terrorists." His analyses of FEMA, DHS, 9/11, and Katrina are incisive. He makes a very strong case for the need to make major changes in what has seemingly become a rather business-as-usual response to past catastrophes and a pervasive unwillingness to adequately anticipate future catastrophes. I consider this book essential reading for all RISKS readers. The book very clearly addresses the computer-related risks as well as many others. The holistic view of the book is absolutely essential if we are going to confront the next catastrophe(s). I recommend it highly. PGN [I note an ambiguity in the subtitle that most of you will probably miss. In addition to the intended emphasis on Reducing Our Vulnerabilities, there is an unintended secondary interpretation (as in "Reducing a complex problem to a simpler problem"), suggesting that if (for example) we could get rid of all of the computer-related risks that result from flawed designs, buggy implementations, human errors in operations, and so on (and which are so prevalent in RISKS), we could reduce our vulnerabilities to only a much smaller subset, namely, just natural, industrial, and terrorist disasters -- and nothing else. This may seem obscure to nonEnglish speakers, and is clearly not what is meant by the title, and thus I include it here as a squarely parenthetical aside.]
Federal computer networks are being targeted on an unprecedented scale and recent high-profile compromises at the Departments of Commerce and Sate are likely just the most visible symptoms of a government-wide security epidemic, government security experts told a House Homeland Security Committee hearing. [Source: Hackers Increasingly Gaining Access to Networks, Congress Is Told, Brian Krebs, *The Washington Post*, 19 Apr 2007]
Two Italian hackers have figured out how to send fake traffic information to navigation systems that use a data feature of FM radio for real-time traffic information. Using cheap, off-the-shelf hardware, they can broadcast traffic data that will be picked up by cars in about a one-mile radius, the hackers said during a presentation at the CanSecWest event here. "We can create queues, bad weather, full car parks, overcrowded service areas, accidents, roadwork and so on," Andrea Barisani, chief security engineer at Inverse Path, a security company. "Traffic information displayed on satellite navigation systems is trusted by drivers. Normal people do not think that you can do nasty things." Barisani and hardware hacker Daniele Bianco discovered that the system used by many navigation aides to get traffic data isn't secured. The data is sent using the Traffic Message Channel (TMC) of the Radio Data System (RDS), a standard way of transmitting data over FM radio also used to display station names and program titles. [Source: Joris Evers, CNET News.com, 20 Apr 2007: PGN-ed]
KPMG UK has produced a report to help us identify people who would defraud our companies. It is interesting, mostly in terms of the questionable nature of the conclusions. http://www.kpmg.co.uk/pubs/ProfileofaFraudsterSurvey(web).pdf The profile is based on 360 cases of detected and investigated fraud, in Europe, South Africa, and the Middle East. The 38 page report is initially long on platitudes, although is does provide data in the later stages. The "personal" profile (on page 8) is probably the most interesting part: 70% of fraudsters were between the ages of 36 and 55 years old, and so in the later stages of their career. 85% male. 68% acted independently. 89% insiders. (We knew that ...) 60% senior management. An additional 26 % of frauds involve management level persons bringing the total to 86 % of profiles involving management. 87% employed 2 years or more at the company defrauded. (Highest proportion in the 3-5 year range.) The internal fraudster most often works in the finance department followed by operations/sales or as the CEO. The response suggested by the report is vague. The recommendations are the same that we've all heard, with a heavy emphasis on "internal controls." However, the data in the profile doesn't necessarily support this advice: internal controls are not terribly effective, according to the reports. confession of perpetrator 2% negligence of perpetrator 2% complaints by suppliers 4% accidentally 8% complaints by customers 9% suspicious superior 9% internal controls 10% external controls 10% management review 21% whistle blowing 25% (The type of fraud is also interesting: counterfeit 1% insider trading 1% money laundering 2% breach of secrets 2 % other fraud 9% embezzlement 10% theft of other assets 10% false financial reporting 20% theft of cash 22% corruption 23% This is the data from Europe. Theft of cash and "corruption" are higher in South Africa and the Middle East figures.) firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev/rms.htm
The U.S. Department of Agriculture has for many years publicly been listing Social Security numbers of about 30,000 people who received financial aid from two of its agencies, raising concerns about identity theft and other privacy violations, apparently unbeknownst to DoA and Census Bureau officials -- until an Illinois farmer stumbled onto the data via Google at FedSpending.org. [Source: U.S. Database Exposed Social Security Numbers, Ron Nixon, *The New York Times*, 21 Apr 2007; PGN-ed] http://www.nytimes.com/2007/04/21/washington/21data.html?th&emc=th
The automated translation of a color description by a Chinese manufacturer into English resulted in an ethnic slur (which I'm not repeating here due both to its being offensive and to avoid tripping inappropriate word filters). While there are periodic lists circulated around of mistranslations, this one wasn't funny but rather quite offensive. There's the usual level of finger-pointing between the retailer, wholesaler, and manufacturer of who is responsible. Some lessons learned: - Translations should be checked by a native speaker to ensure both accuracy and appropriateness. - Relying on automated translations as a cost saving measure isn't a good idea, for anything other than getting the gist of an idea. http://www.cnn.com/2007/WORLD/americas/04/19/canada.couch.ap/index.html [Also noted by several others. PGN]
A prisoner was wrongly released after a fax was received from a grocery store stating that the Kentucky Supreme Court had demanded his release: http://www.cnn.com/2007/US/04/21/wrongly.freed.ap/index.html I have always complained that network security is held to a standard that other technologies do not have to meet. Apparently others are noticing this as well...
While waiting to board a different flight in the United Terminal at JFK Friday evening, April 20, I was bemused to hear an announcement repeated perhaps 20 times in a two-hour period: "Attention passengers on British Airways flight 1502 to Manchester: Due to system problems on this aircraft, there will be no inflight entertainment and no overhead lighting during the flight. We apologize for this inconvenience; passengers who have questions may come to Gate xxx." I guess my own question would have been: Do I want to head out over the Atlantic in an aircraft that's having "system problems" and especially electrical ones? (Maybe it would depend on whether I'd gotten an upgrade or not . . .) A. E. Siegman, McMurtry Professor of Engineering Emeritus, Stanford University (650) 326-4360 email@example.com [This seems to be a not uncommon failure mode, which I presume the repair folks believe is unrelated to the flight controls. On the other hand, RISKS readers are generally suspicious of such beliefs. I suppose that if this particular problem cannot be fixed quickly enough, the airline might prefer not to delay the flight, which of course can have propagational effects on international schedules. PGN]
The current French presidential election provides rich material for RISKS, in particular many stories related to the somewhat botched introduction of voting machines. Here is a report on the Web consequences, as seen by one "Internaute", of today's (22 April 2007) first round of balloting. French law prohibits any publication of estimates in the last two days and until the closing of the polls at 8 PM; in recent years it was extended to cover the Internet. Partly because penalties for breaking the ban are serious, and partly because the rule enjoys broad support, no reputable French Web site was tempted to publish any estimate before the deadline (although lemonde.fr reported at 18:46 that the mood at one of the principal candidate's headquarters was "not ebullient", a rather blatant giveaway). Neither was it easy to find a list of links to the sites of foreign news media, to which the rule cannot apply. Several of these foreign sites, especially those of French-language papers in Belgium and Switzerland, had announced that they would start giving out estimates at 6 PM, when exit polls provide a credible picture. *La Libre Belgique*, for example, explicitly invited Web readers to come at 6. Starting in the afternoon, most of these sites (*La Libre Belgique*, *Le Soir* from Brussels, *Le Matin* from Lausanne...) were, for me at least, impossible to reach; they were timing out. It looked like all of wired France (Internet penetration per Nielsen: 50.3% in late 2006) was trying to access them, and either the servers or the bandwidth couldn't follow. Long into the evening I still couldn't reach lalibre.be. I got my first taste of the results around 6:30 through an Italian site, *Corriere della Sera*; other Italian newspapers such as *La Repubblica* had estimates shortly thereafter. One of these reports pointed to Swiss French-speaking TV (I hadn't checked tsr.ch earlier but it was working properly when I did). The Swiss German-language newspaper sites (NZZ, *Tagesanzeiger*) published the estimates a few minutes later. In stark contrast with foreign French-language sites, none of the non-French-language sites showed any sign of stress. At some point in the afternoon someone at *Le Temps* (Geneva), whose site had been slow but reachable, had the good sense to replace the site's usual home page -- with the usual combination of ads, photographs, cartoons, links, tables, CSS and other complicated layout -- by a text-only page entirely devoted to a concise report about the French election, with a note that traffic was unusually high and that the normal page would be restored later. As a result one could find estimates there too. Le Soir eventually did the same. If this experience is representative, it would seem that the infrastructure for many newspapers' online editions isn't ready to withstand a steep surge in visits. True, today's situation was exceptional because of the news blackout about an event that has generated considerable passion (the turnout was the highest ever, and the outcome was hard to predict) in a large country whose language is spoken by much smaller neighboring communities. Scaling up a site to accommodate millions of foreign visitors on a couple of afternoons every few years probably doesn't sound like an attractive investment; it is unlikely to yield many new advertisers or subscribers. Still, one can wonder about the effect on these sites of the next major news event. It is surprising to see how few sites had *Le Temps*'s reaction of providing a pared-down, text-only version of the site with the key information that visitors are seeking. Granted, such sites are there to sell advertisements, not provide a public service; but a site that no one can access doesn't do much for advertisers or anyone else. It seems that other media sites didn't have any contingency planning, or didn't even realize what was going on. The second round, of only two candidates, is two weeks from now, with the same law in force and presumably even higher stress and eagerness to know. It's going to be interesting to see if the sites are better prepared this time. One site, cnn.com, was as usual available all the time without any delay; until shortly before 8 all that one could find on the home page was a link to older material about the campaign. The text of the link was expressing a world philosophy more eloquently than many a long speech: "French polls open; candidates differ on U.S.". Bertrand Meyer ETH Zurich http://se.ethz.ch Eiffel http://www.eiffel.com
"Netcraft is showing that an event happened in the Ohio 2004 election that is difficult to explain. The Secretary of State's website, which handles election reporting, normally is directed to an Ohio-based IP address hosted by the Ohio Supercomputer Center. On Nov. 3 2004, Netcraft shows the website pointing out of state to a server owned by Smartech Corp. According to the American Registry on Internet Numbers, Smartech's block of IP addresses 220.127.116.11 - 18.104.22.168 encompasses the entire range of addresses owned by the Republican National Committee. Smartech hosted the recently notorious gbw43.com domain used from the White House in apparent violation of the Presidential Records Act, from which thousands of White House e-mails vanished. Can anyone suggest a good explanations for this seemingly dubious election-eve transfer?" http://www.alternet.org/story/50941 http://politics.slashdot.org/politics/07/04/24/1735213.shtml http://toolbar.netcraft.com/site_report?url=http://election.sos.state.oh.us
An audit of the November 2006 general election in the Cleveland area has found that hundreds of votes were lost, others were recorded twice, and software used to count the ballots was vulnerable to data problems. [Source: Bob Driehaus, *The New York Times*, 20 Apr 2007; PGN-ed]
[David's note refers to the major inherent problem with Internet voting, coercion/vote selling. PGN] a) Go to voter's house ahead of time. b) "See my gun? You will vote as I tell you, while I watch; or I'll take your daughter with me... and sell her, if she's still alive." c) Voter decides that Gov. Dewey is not a bad choice after all. Repeat as needed. I can't recall who coined the phrase "rubber-hose cryptanalysis" but it also applies to voting. There IS a reason we have the secret ballot. The RISK? Worrying about only one RISK, and ignoring the others...
(Rieden, RISKS-24.64) > ... when designing ANY software change, the qualification of the hardware > (and the required test cases) should ALWAYS at least be formally reviewed > and repeated where necessary. Well, the NSA is well aware of this, and I'm a little surprised that the people who design aircraft -- especially military aircraft -- aren't. If you look at DCID 6/3 and supporting material you will see a pretty good set of specifications. This applies especially to systems designed for Protection Level 7 -- systems that will handle data spanning from unclassified/general public to Top Secret with one or more Special Access Need-to-Know Compartments. Such systems would need to be built to EAL-7 (formerly called A-1 in the old Orange Book). This requires a full mathematical specification of the software, mathematical proof that the specification preserves security, and a line-by-line correspondence between the specification and the code. In practice, this takes a lot of time. Just building a system of any size takes time, and then you need to add effort _and time_ to write and prove the formal specification and the code correspondence. And then the whole thing has to be reviewed by a certifying authority. So the usual result is that you have built an EAL-7 boat anchor. By the time you've done all this, your system is two years out of date -- too old to be useful in today's rapidly evolving world. The best you can do is keep the same software and match it with newer, more modern hardware. But then the new hardware has to go through the certification process too. The only commercial product I'm aware of that meets EAL-7 is the Data Diode -- magnificent in its simplicity. It keeps data from flowing the "wrong"way (from more classified to less classified) by the simple technique of not providing a hardware path for that data flow. At its heart is a fiber-optic cable, one end has (only) transmitters, and the other end has (only) receivers. There is simply no way to move data the other way.
http://www.globeinvestor.com/servlet/story/GAM.20070421.RRIM21/GIStory/ A few excerpts: RIM co-chief executive Jim Balsillie dismissed those worries, telling Reuters News Agency that "systems are in place so that this kind of thing, as incredibly unlikely as it is to happen, is all the more unlikely to happen again." [where have we heard that one before?] Essentially, he said, "it was an outage overnight when there was an upgrade." But the outage has also raised concerns about the way RIM handles e-mail data, Mr. Levy said, given that all traffic is routed through a single communication centre. Robert Israel, Department of Mathematics, University of British Columbia Vancouver, BC, Canada http://www.math.ubc.ca/~israel
> In running log files from the past few weeks I've noticed that the times > seem to be an hour off from what I remember the time would have been when > the data was taken. When converting between local time and UTC, Microsoft has long held the peculiar philosophy that whether Daylight Saving Time is *currently* in effect should be used to determine the offset to be applied rather than whether DST was (or will be) in effect at the time being converted. This has caused no end of problems, but they insist that that is how it's supposed to work and refuse to fix it.
The solution seems rather obvious. Instead of using software to account for all the idiosyncracies in time calculation, the process should be data driven, through a configuration file. When will we ever learn? Charlie Shub, University of Colorado at Colorado Springs (719) 262-3492 http://cs.uccs.edu/~cdash firstname.lastname@example.org
> "Don't wait until the last minute is the moral of the story." Actually, the moral of the story is: 1. Save money by not bothering to load test your software. 2. Blame your customers for the performance and reliability bugs you didn't find and shift the costs off to them should any costs occur. 3. Convince--somehow or other--the Federal government that you shouldn't be fined or at least stripped of your privilege to process taxes online. Since they seem to have pulled off this little trifecta, the title of this story is: "Software Quality Doesn't Matter: Part 11,765 in a Continuing Series." Rex Black, President, American Software Testing Qualif. Board; Pure Testing, 31520 Beck Road, Bulverde, TX 78163 1-830-438-4830 www.rexblackconsulting.com
I am not a tax professional, but I think it is worth pointing out that the April 15th (17th this year) date is the deadline to pay any income tax owed without penalty. If the government owes you a refund, there is no penalty for filing a return after this date. The IRS is more than happy to remain caretaker of your money. I believe a widespread misunderstanding of the deadline was contributing factor to the filing frenzy and resulting online meltdown. Perhaps Intuit should add this information to its "try again later" messages.
BKINSCAB.RVW 20070119 "Information Security Awareness Basics", Fred Cohen, 2006, 1-878109-39-1 %A Fred Cohen %C 572 Leona Dr, Livermore, CA 94550 %D 2006 %G 1-878109-39-1 %I Fred Cohen and Associates %O U$24.00/C$27.97 925-454-0171 all.net %O http://www.amazon.com/exec/obidos/ASIN/1878109391/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1878109391/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1878109391/robsladesin03-20 %O Audience n+ Tech 2 Writing 3 (see revfaq.htm for explanation) %P 46 p. %T "Information Security Awareness Basics" This booklet is written as an employee security awareness manual. It can be purchased and used as such (by a small business), or customized and augmented by other materials (for a large enterprise). (If you intend using the primer "as is" for your employee manual, note that you should read it first, and ensure that you do, in fact, provide the services, and have the policies, that Cohen recommends. This should not be onerous, as the procedures outlined are quite reasonable, for any but the smallest business.) The content is well-written, readable and clear, and covers a number of basic points that are often neglected (such as the importance of reading and understanding the contract with the employer, and, by extension, the employer's policies.) (The topics are approximately one page in length, or less, and are all, with one exception, on separate pages.) A significant portion of the early material is concerned with personal physical (rather than information) security. This is a very good arrangement, not only because it demonstrates concern for the well-being of the employee, but also since it starts with the more familiar (less esoteric) matters, and is a good lead-in to the concepts of information security. Well thought out, well written, and clear. This is a useful item for those who do not have the time to create their own security awareness materials, and a model for those who do. copyright Robert M. Slade, 2007 BKINSCAB.RVW 20070119 email@example.com firstname.lastname@example.org email@example.com http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer