Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
*Flight International* 10-16 Oct 2006 attributes the wiring-matching problems in the Airbus A380 assembly to problems with design software, reported in an article by Max Kingsley-Jones on p5. The A380 aircraft has approximately 500 km (300 miles) of internal electrical wiring, which is aluminium rather than the traditional copper. It has been widely reported that the wiring harnesses on body parts fabricated in Hamburg, Germany did not match those of their neighbors built in France when they were mated in Toulouse. This has led to extensive delays in delivery dates, culminating in the resignation both of the former Airbus chief, Gustave Humbert, a few months ago and now his successor, Christian Streiff, this week, as well as the resignation of EADS co-chief Noel Forgeard, who as Airbus chief was largely responsible for the initial development of the A380. Airbus is forecasting that full production will not be achieved until 2010, and that only 39 A380 aircraft will be delivered by the end of 2009, "compared with 107 originally planned and 80 anticipated under the rescheduling announced in June 2006." The 68-aircraft shortfall is reported by Kingsley-Jones to be worth USD 19 billion in lost revenue, based on a list price of USD 282 million each (note: it is believed that few aircraft sales take place at list price). Airbus claims to have underestimated the work required to install (press-speak: "complete the installation of") the harnesses. Kingsley-Jones cites Airbus: "The root cause of the problem is the fact that the 3D digital mock-up [software], which facilitates the design of the electrical harnesses installation, was implemented late and that the people working on it were in their learning curve." It looks as if Airbus is claiming that the wiring design software was a single point of failure. Given what we all know about the risks of developing new SW tools, it seems appropriate to ask why no risk-mitigation measures were put in place as the SW was developed. Indeed, the former chief executive Christian Streiff sees the problems more generally, reported as saying that Airbus is not yet an "integrated company" and "doesn't yet have a simple and clear organisation". Peter B. Ladkin, Causalis Limited and University of Bielefeld www.causalis.com www.rvs.uni-bielefeld.de
With respect to the penultimate paragraph in the preceding item, John Rushby pointed out to me that it had been reported that Airbus Hamburg and Airbus Toulouse were using different versions of CATIA software which had incompatible file formats. CATIA is the CAD-CAM software which Airbus, Boeing and Sikorsky, amongst others, have been using for a while. The reports say that engineers in Germany and Spain used Version 4, while those in the UK and France use Version 5, and it is "no secret" (Newton, see below) that those versions are "incompatible at the file format level". The problems and challenges with using different versions of SW, indeed with data in different formats, are well-known to software managers (if not to almost everyone who has used a PC and tried to upgrade some favorite SW), and Airbus must have had some measures in place to address those issues. Those measures obviously did not suffice. But choosing and evaluating the measures is much more a management issue than a SW issue. The Bloomberg News story by Andrea Rothman from September 29 is at http://www.bloomberg.com/apps/news?pid=20601085&sid=aSGkIYVa9IZk and a technical discussion, including some sensible comments about the situation with company-critical-software updates by Randall S. Newton at http://aecnews.com/articles/2035.aspx Peter B. Ladkin, Causalis Limited and University of Bielefeld www.causalis.com www.rvs.uni-bielefeld.de [More on the Bloomberg item follows, from Mike Martin. PGN]
Bloomberg has reported that the wiring problems that have delayed A380 deliveries yet again are related to incompatibility between versions of CAD software being used: http://bloomberg.com/apps/news?pid=20601109&sid=aSGkIYVa9IZk&refer=exclusive ... engineers in Germany and Spain stuck with an earlier version of Paris-based Dassault Systemes SA's Catia design software, even though the French and British offices had upgraded to Catia 5. That meant the German teams couldn't add their design changes for the electrical wiring back into the common three- dimensional digital mock-up being produced in Toulouse, [Charles] Champion [former head of the A380 program] says. Efforts to fiddle with the software to make it compatible failed, meaning that changes to the designs in the two offices couldn't be managed and integrated in real time, he says. ``The situation worsened when construction and tests of the first A380s generated demands for structural changes that would affect the wiring. The changes in configuration had to be made manually because the software tools couldn't talk to each other.'' Catia file formats changed between version 4 and version 5. An initiative has now begun to standardise software tools across the program. According to the latest report on 3 Oct 2006, cost of the consequent two-year delay to Airbus is estimated to be 4.8 billion euros. Emirate Airlines accounts for 45 of the 159 A380s currently on order and according to Bloomberg yesterday is said to be "reviewing 'all options'". If it cancels, the whole program could be in trouble, http://www.bloomberg.com/apps/news?pid=20601087&sid=aNULET1PwpvE&refer=home. While there has been no statement about the reason, the fatal decision to not upgrade software in Germany and Spain may have been taken so as to avoid delay to the schedule.
In light of the recent mid-air collision in Brazil, Philip Greenspun posted an article to his weblog where he suggests that too much precision in navigation can be a bad thing. It's fairly short so I've 'reprinted' it below (which his CC license allows :): The recent mid-air collision in Brazil of a new regional airliner (fitted out for use as a business jet) and a Boeing 737 has people baffled. How could two brand-new airplanes with advanced avionics, flown by two professional pilots in each plane, collide at 37,000 feet? The precision of modern avionics may well have contributed to this collision. Airplanes under instrument flight rules fly from one navigation beacon to another along published standard routes. In the old days, with radio navigation receivers and pilots flying by hand, a plane wouldn't fly its clearance exactly. The airways include a tolerance for error of +/- 4 miles. If you're 4 miles to the right of course, in other words, you're still legal and safe from hitting mountains or other obstacles. Altitude was similarly sloppy. If you reached for a drink of coffee or to look at a chart, you might drift up or down 200 feet. Air traffic control wouldn't get upset. How does it work now that the computer age has finally reached aviation? The GPS receiver computes an exact great circle route from navaid to navaid. All GPS receivers run from the same database of latitude/longitude coordinates, so they all have the same idea of where the Manchester, New Hampshire VOR is, for example. The autopilot in the plane will hold the airplane to within about 30 feet of the centerline of the airway and to perhaps 20 feet in altitude. If two planes in opposite directions are cleared to fly on the same airway at the same altitude, a collision now becomes inevitable. Almost any other system would be safer. If you sent airplanes up to fly in random point-to-point paths, e.g., from Boston to Denver, they'd be less likely to encounter one another. If you kept the airway system, but introduced some slop into the avionics so that planes always flew 1 mile to the right of an airway and + or - 200 feet in altitude, they'd be less likely to encounter one another. If you replaced the precise autopilots with imprecise humans, planes would be less likely to encounter one another. If you replaced the high- precision GPS receivers with low-precision VOR receivers, planes would be less likely to encounter one another. http://blogs.law.harvard.edu/philg/2006/10/06/mid-air-collision-in-brazil-when-precision-kills/
> An awful lot of modern user interface design seems to me to amount to > printing little silkscreened arrows next to buttons that were hopelessly > misplaced to begin with. I was a guest once at a hotel with a TV remote that had the entire silkscreen worn off from too much use. Luckily none of them were "Buy now" or anything that cost more than a few minutes of frustration. Taking this idea to an extreme, the Das Keyboard makes a fetish out of it by removing all labels from the keycaps to create a totally black keyboard. Apropos the John Denver crash: > [This of course might reminds us of John Denver's final flight, in which > he thought he had run out of gas on one tank and tried to switch tanks. > The lever positions were UP for both tanks off, RIGHT for the left tank, > and DOWN for the right tank. PGN] The NTSB report Probable Cause listed the switch orientation as a contributing factor, but the primary one was the switch location behind the pilot seat. The NTSB found that "when investigators attempted to switch fuel tanks in a similar Long EZ, each time while an investigator turned his body the 90 degrees required to reach the valve, his natural tendency was to extend his right foot against the right rudder pedal to support his body as he turned in the seat." As reported in RISKS-20.43, the original builder of the rear engined experimental aircraft deviated from the designers plans, and selected the non-standard location to avoid having any fuel plumbing in the cockpit. A good idea, perhaps, but one with plenty of other repercussions.
Spiegel-Online reports on the "Stone-Age" technology used for security on the Transrapid test track: http://www.spiegel.de/panorama/0,1518,439302,00.html Characteristic for a number of other unnamed technology is the record of the communication between the central control and the cars. [Other reports have said that normally the oral command to proceed is given only after the controllers have seen that the maintenance car is in its dock (it is with sight of the tower) *and* they have spoken with the operators.] The communication record (sort of the black box of airplanes) is recorded on 8-track tapes. The tapes in use have been used over and over again and are almost not audible. The system also tries to "optimize" the tape use by storing every transmission on the "next free track" which is not necessarily the n+1th mod 8 track. There is no time stamp, so the investigators will have to piece together a puzzle of almost inaudible bits of communication, trying to figure out exactly what happened. It appears that the investigators have no 8-track playing equipment in all of Germany and are asking for international help. [Mine died *years* ago! - dww] The first order of business will be trying to make a copy of the tape, because they are fearful of destroying it by replaying it too much. In another report criticism has been leveled on the security concept for the transrapid track to be built in Munich. http://www.br-online.de/bayern-heute/artikel/0609/26-transrapid/index.xml It seems that the concept goes like this [grossly shortened and distorted by dww]: 1. The Transrapid is absolutely secure, no accidents can happen. 2. Not even in a tunnel. 3. So we don't need a fancy security system. No more detailed reports are expected until the communications can be deciphered. Prof. Dr. Debora Weber-Wulff, FHTW Berlin, Internationale Medieninformatik 10313 Berlin http://www.f4.fhtw-berlin.de/people/weberwu/ +49-30-5019-2320
The official investigation into the Transrapid crash (a magnetic levitation train crashed into a non-maglev service car at approximately 170 km/h, killing 23 people on 22 Sep 2006) has determined that there is no "technical" failure behind the crash, but that the fault lies with the trainman in the maglev vehicle (who died in the crash) and the two dispatchers who let the train start although the service train was still on the track. There were, however, two previous accidents involving the service cars, according to the Tagesschau-online: http://www.tagesschau.de/aktuell/meldungen/0,,OID5999452,00.html On 10 Dec 2004 two service cars running in opposite directions collided in the fog because of icy conditions. The impact was only at 20 km/h, so no people were hurt, but the collision caused 100,000 euros worth of damage to the cars. At this time the employees of the Transrapid requested additional security precautions, which were denied on the grounds of being an unnecessary expenditure. In Jan 2005 there was another accident (that has been acknowledged by the state government) in which a service car hat an attachment folded down under the track and smashed into one of the stilts the tracks are built on. There were no people hurt in this incident, either. A speaker for the government insists that everything is fine, these accidents were recorded but not reported, since they were such "small accidents". An ethical question: even if the company running the train is found to be legally guiltless, shouldn't they have set up some sort of fool-proof signaling system after that first accident? Further reports say that a German and an American lawyer are suing Siemens, who are responsible both for the security system of the Transrapid and for the cable car in Kaprun, which caught fire on 11 Nov 2000, killing 155 persons, in the USA because the company has a subsidiary there. (http://www.tagesschau.de/aktuell/meldungen/0,1185,OID5980314_REF_NAV_BAB,00.html)
Kjetil Torgrim Homme's account of a mistakenly typed bank account number in an electronic transaction causing a transfer to a third party astounds me. German banks require not only the account number but also the recipient name to match the account number before they will initiate a transfer. The danger of a typo is largely that the discrepancy will cause an attempted payment to fail, and you will only be informed in time if you print out your account statement shortly afterwards, since German banks issue on-demand statements only. This may well lead to tensions with creditors if one forgets to check. This same danger has been present in another form for some time. If one fills out a payment slip by hand, characters or numerals may be misread by the automatic reader, leading similarly to non-payment. German banks do not issue checks (cheques); account-to-account transfers are the usual non-cash means of payment (apart from credit cards, whose use is still not widespread, compared with the US or UK). Peter B. Ladkin, Causalis Limited and University of Bielefeld, www.causalis.com www.rvs.uni-bielefeld.de
Several blogs  have pointed out that Google Code Search can be used to discover vulnerabilities in the indexed code. One can find SQL injection possibilities , potential buffer overflows  and backdoor passwords . But it's not just security holes in software that you can find. One particular search I did revealed a file containing a particular person's entire collection of usernames and passwords. It included several banking account numbers and passwords, SSNs for him and his wife, keys for popular software and mortgage payment details. Assuming the passwords hadn't changed since, I had more than I needed to steal all his money and his identity. Irony of ironies, the file was included, as plain text, in the source code package for a "secure password storage" product this person had written and posted to the web! I sent him an e-mail a couple of weeks ago, and he replied saying that some of the data was out of date, and he would change the rest. But it's not easy to change bank account numbers and SSNs. The RISKs: testing security software with confidential data; when working on software, not keeping the development version and the version you use separated.  http://www.kottke.org/06/10/google-code-search  http://www.google.com/search?q=inurl:%22SQL+select%22+inurl:asp  http://www.google.com/codesearch?q=buffer+%22should+be+big+enough%22  http://google.com/codesearch?hl=en&lr=&q=%22backdoor+password%22+%28warning%7Cshell%29
Somehow I forgot the password I reset recently on my American Express Blue Cash card. I thought I knew it, and figured I mistyped it, because it's a somewhat strong password, so I entered it three times and got "locked out". This turns out to mean that they asked me for my four- to eight-digit "secure code". These are inherently less secure than the normal password, so I'm in the habit of generating a random number and forgetting this, but out of curiosity I also tried this three times, just to see if it would really lock me out. Why do so many services use these? I was soon told to call customer service, who asked me about the card number and the cvv on the card, my name, and one prior address. Now my current address is easily available, and my prior addresses are a matter of public record, as they warned me, and easy to discern if you know some basic facts about me, so it's apparently appallingly easy to pretext me. At this point I was given a temporary password with which to log in and change my real password, so far so good. They also asked me to set my "secure" number. I asked if I could change that on the web site. No. I asked if they could put me through to something I could type it into. No. I had to reveal it to the representative, and the representative encouraged me to label it, e.g. as mother's birth date, etc. Random numbers away! So there's no security in a procedure you can circumvent with insecure information, but at least their normal password procedure appears relatively strong, so I thought perhaps it won't take *too* much convincing or education. I reset my normal password, only to be told: "You Have Successfully Changed Your Password Please record your new Password." Thanks, AmEx. Good advice! Gregory A. Marton http://csail.mit.edu/~gremio/
US election systems are in a crisis — maybe students can find the way forward. In the 2007 Collegiate Voting Systems Competition, student teams will design, implement, analyze, attack and evaluate complete voting system that must have been used in some election, such as one for a student government or organization. Papers describing and analyzing the system will be submitted for the conference and used to select candidates for the final competition. The conference, to be held in Portland in July 2007, will include demonstrations, mock elections, submitted presentations and invited talks. A panel of judges will make awards for the best overall system, best presentation, best attack, and best paper on voting system metrics. VoComp 2007 will be run by UMBC's Alan Sherman with support from the NSF Cyber Trust program and is seen as a way to engage students in nationally important, state-of-the-art security and privacy research projects and course work. More information on the conference, competition, its rules, and an example system is available at http://vocomp.org/.
BKWW3IWB.RVW 20060823 "World War 3: Information Warfare Basics", Fred Cohen, 2006, 1-878109-40-5 %A Fred Cohen fred.cohen at all dot net %C 572 Leona Dr, Livermore, CA 94550 %D 2006 %G 1-878109-40-5 %I Fred Cohen and Associates %O 925-454-0171 all.net %O http://www.amazon.com/exec/obidos/ASIN/1878109405/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1878109405/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1878109405/robsladesin03-20 %O Audience n+ Tech 2 Writing 2 (see revfaq.htm for explanation) %P 314 p. %T "World War 3: Information Warfare Basics" Chapter one asserts that world war 3 is not what most people think it is or will be, and that it is going on right now. (There is also a fairly extensive biography of Dr. Cohen.) A definition of information warfare (or iwar) is the province of chapter two. Cohen starts with the notion that warfare itself is a high-intensity conflict, and then notes that iwar is the manipulation (and protection) of symbolic representations used by the participants in such a conflict. Numerous instances and examples of iwar are explored, and the definition certainly fits all the forms noted. At the same time, it must be said that the definition, while comprehensive, does not appear to assist in formulating responses to the problem. (The mention of marketing as a form of low-intensity iwar is intriguing. I recall a conversation, with an ex-employee of the CIA, as it happens. This person had just encountered the proposal that advertising agencies deliberately used, and reinforced, certain symbols that were associated with specific meanings and emotions. Being part of the direct target audience he had never noticed the practice while I, as an outsider, was just far enough away from the central culture to have observed it for years.) Cohen finally points out that we are all at war, on an information level, with everyone else. Chapter three examines the intensity levels of iwar. The information warfare capabilities of numerous nations, and relative comparisons between various groups, are analyzed in chapter four. Cohen also makes a case for China overtaking the United States as a world leader in this regard. (This seems to have the strongest relationship to the subtitular admonition that "we are losing" the world war 3 that we didn't even know was being fought. However, if so, it seems in some contradiction to statements, in chapters two and three, that "we" are all fighting each other, or that "we" are all in this together.) Criminal activity is reviewed in chapter five, but the material is relatively weak in regard to iwar. The relationship between preaching (especially the dogmatic and extreme forms) and propaganda is clear, so chapter seven's association between religion and iwar is not surprising, but the text does not support the contention in any detailed way. Corporate public relations and business intelligence is discussed in chapter seven. (Of particular interest are the sections on companies against nations and religions.) Chapter eight analyzes propaganda, not only in terms of the component parts, but also in regard to effective countermeasures. Politics, and the various forms of iwar inherent in it, are in chapter nine. Gaming and game theory have been used in warfare and politics for years, and are examined in chapter ten. Chapter eleven looks at electronic warfare, in many of its forms. Information attack tactics, in chapter twelve, repeats procedures that are well known to those dealing with intrusions and penetration testing. Legal issues associated with iwar are outlined in chapter thirteen. Chapter fourteen deals with broad categories of defences that can be mounted against iwar activities. Education is one, and chapter fifteen examines various forms of education that are necessary for effective protection. Finally, in chapter sixteen, Cohen returns to the concept that all of us need to know about information warfare, and to be on guard against it. Ultimately, this book is not about World War Three, but about the information warfare, at all levels, taking place around us every day. While more personal and not as academic as Denning's "Information Warfare and Security" (cf. BKINWRSC.RVW), Cohen's work is, in its own way, just as important, since it addresses the types of propaganda to which almost everyone is subject, likely without being aware of it. copyright Robert M. Slade, 2006 BKWW3IWB.RVW 20060823 firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer