Three of the twelve largest banks in Japan merged. The results weren't pretty, including "more than 30,000 transaction errors and 2.5 million delayed debits" and "2.5 million of the 3 million automatic debits scheduled to be processed on 1 Apr 2002, including utility and credit card bills, couldn't be made on that day". The problem was that each of the banks ran a different system (Hitachi, IBM, and Fujitsu, although no software was mentioned). They build some integration glue, but it didn't work. http://www.computerworld.com/storyba/0,4125,NAV47_STO69943,00.html
This news seems to be reported over foreign wire services, and so may have been reported already but here it goes in any way. Japan's Mizuho Financial group that operates the Mizuho Bank, which has been born out of the merger of three large banks, Dai-Ichi Kangyo bank, Nihon Kogyo bank, and Fuji bank, has started its merged new operation starting on 1 Apr 2002. (There is also another holding bank, but the Mizuho bank is the one where ordinary people have accounts carried over from the three banks.) Since that day, the online banking transaction system of the new bank has been plagued with problems. On 1 Apr, the ATM malfunctioned and many users of the new bank could not withdrawal or deposit money. That continued until the next day. I thought this was a labor pain often found in a new operation, but no the problem persisted and the cause seems to run much deeper than I originally thought. Now for the last few days, the online banking transactions for payment of utility bills such as gas, electricity, water, and credit company payments are delayed heavily due to problems of unknown cause. This morning's Asahi Shimbun newspaper (Yokohama edition) carried a top article that stated the management of Mizuho FG admitted the back log of transactions amounts to more than 2.5 million. About three million such payments expected to take place on the 1 Apr could not be finished on time and 105,000 transactions remains unfinished even as of 5 Apr. The delay affected the subsequent processing of other transactions and the unfinished count exceeded 2.5 million on April 5th. (The fifth day of each month is the payment day of credit companies and thus there were many transactions to take place yesterday.) About 30,000 incorrect double withdrawals, and about 5,000 double deposits were found and corrected. (Not all of them, it seems, to the evening NHK news I just heard.) According to the bank, the current accumulation of delayed transaction would need the whole next week to finish. The completion notification of utility bills payment to utility companies is also delayed very much. Such delayed notices are believed to be more than 5 million cases. (It seems as if the bank don't know exactly the status of the payment...) The bank management admitted that although they have tested the integrated online transaction systems many times before the complete merger and the start of operation on 1 Apr, their expectation of the workload was not accurate enough. (Above is my own translation.) Since many Japanese companies have its fiscal year ends at the end of March, and starts a new fiscal year in April, the Monday being the first week day of April had more workload than expected according to the statement found in the newspaper article. I noticed that the three banks closed the banking systems on Friday evening of the previous week and so I thought they took the time to move to the unified operation smoothly. But, after the fact, some articles in newspapers suggested the previous testing period of the whole merger and unified operation was not long enough for the large scale operation at all. Also, there seems to have been a long period of discussion as to how the operations were to be unified and thus the implementation period became shorter than expected. Dai-ich Kangin used Fujitsu, Fuji used IBM, and Nihon Kogyo used Hitachi computers. The unified system seems to have been designed by Hitachi. The computes seem to be the mainframe UNIX types. As of now, it is not clear where/whether the problem lies in the integrated system hardware components and vendor supplied software or is in the application programmed by Mizuho. I have an account at Dai-ichi and so is now a Mizuho customer. One solace is that the bank responded to the customer concern quickly and opend telephone hot line to track one's payment status, etc.. I have not tried the telephone number yet. The bank stated publicly it will cover the cost incurred due to the delayed transactions. A big financial loss to the bank, I guess. A failure in a spectacular manner. This will remain in Japanese banking history.
Eighty-five percent of respondents report having been victims of computer crime, costing them millions of dollars, according to a survey by the Computer Security Institute and the FBI. The study, which polled 583 computer security experts in business, government agencies, medical institutions and universities, concluded that the most serious losses stemmed from theft of proprietary information. In addition, almost all of the organizations had suffered from computer virus attacks last year, and 90% said they had been victims of Web site defacement in 2001, up from 64% a year earlier. "Organizations that want to survive in the coming years need to develop a comprehensive approach to information security, embracing both the human and technical dimensions," says Patrice Rapalus, director of the Computer Security Institute. In response to the growing threat of cybercrime, the FBI has set up the National Infrastructure Protection Center and has formed regional Computer Intrusion Squads in several offices throughout the U.S. [BBC Online 8 Apr 2002; NewsScan Daily, 8 Apr 2002] http://news.bbc.co.uk/hi/english/sci/tech/newsid_1916000/1916655.stm
One proposal for improving airport security has been the creation of hard-to-counterfeit "trusted traveler" ID cards for frequent travelers, but software developer Richard P. Eastman asks the obvious question: "What makes a trusted traveler? The guy who travels all the time; who travels on business; who has a reason to travel. Does that mean the terrorist can't penetrate that group? Of course he can." Beyond objections of that sort, civil libertarians have been arguing that ID cards for travelers will set a dangerous precedent. Barry S. Steinhardt of the American Civil Liberties Union predicts, "Quickly enough, policy makers are going to say, 'If this works, let's require everyone to go through background checks before they get on a plane.'" [*The New York Times*, 9 Apr 2002; NewsScan Daily, 9 Apr 2002] http://www.nytimes.com/2002/04/09/technology/09PASS.html
Local U.K. governments in Liverpool and Sheffield are gearing up to allow citizens to vote using SMS (Short Message Service) text messages and the Internet in elections 2 May 2002. [http://www.computerworld.com.au/idg2.nsf/All/E7E9EB212B30B99FCA256B960079B1B2!OpenDocument&NavArea=Home&SelectedCategoryName=News]
The 2 Apr 2002 edition of *The Australian IT* (australiait.com.au) ran a story about the Royal Children's Hospital in Melbourne, Australia. They've just finished upgrading their patient administration software. The software hasn't yet replaced the need for paper records but provides the foundation to do so. It uses a browser front-end. Four years in the implementation, one of key drivers was the old software was unable to support patient numbers of more than six digits. The software went live on February 11. The 1,000,000th patient arrived in March.
On 10 Apr 2002 at 0605 BST, air-traffic control computers failed at the West Drayton control center near Heathrow Airport, causing subsequent failures at the control center in Swanwick, Hampshire. Disruptions lasted up to two hours, with controllers working by hand to track planes. According to a BBC report http://news.bbc.co.uk/hi/english/uk/newsid_1920000/1920527.stm this is the second breakdown in ATC in Britain in two weeks. Although the current failure is being attributed to "creaky" old systems that are unstable, the previous incident was attributed to a data-input error. [Comments from MK: The comment on data-input error conveys a belief that having a system crash because of incorrect inputs is understandable and acceptable. It isn't. Good design includes edit checks on inputs, especially inputs that can cause kernel panics. When there are forbidden combinations of inputs, table-driven checks can exclude such combinations before they are sent for further processing.] M. E. Kabay, PhD, CISSP -- AssocProf Information Assurance Dept CompInfoSys, Norwich University, Northfield VT http://www2.norwich.edu/mkabay/index.htm
An example of the risk of "simplifying" an interface: while on vacation recently, I rented a new-model car. One reason I rented it was to take my daughter to a drive-in movie since these are rapidly disappearing and I wanted her to have this experience. This drive-in, in Tucson, Arizona, does not have the speakers you attach to your car window. Instead, you tune your radio to a specified FM channel to get the sound for the movie. As I started up the car to drive to the movie that night, I noticed that the headlights came on by themselves, presumably because it was dark out. We got to the movie, parked, found the radio station with the movie's soundtrack, and discovered that there is no way to turn off the headlights while keeping the power on to the radio! One can imagine the (overly) clever engineer thinking "why would anyone want to sit in a car with the lights off and the power on?" Whereas some of us could come up with at least a couple of reasons for doing this, evidently Detroit isn't that imaginative. Devon H. McCormick, CFA firstname.lastname@example.org
Like Donald A. Norman, BMW's announcement of their intelligent 7 Series sent a shiver up my back. In my case this was based on my experiences with an early version of one of their intelligent cars (a 1986 520 injection I was still using in 2001). When BMW transfered (in connection with the Rover disaster) their dealership in Finland to a different company, they lost all expertise among their mechanics of the era before "computer-based" maintenance. This led to such funnies as my car refusing to start once in the middle of summer after a break of about 10 minutes in use; then me getting it to start after a couple of hours of leaving it alone and taking it to the dealership only to be told that by starting it it meant they were unable to download the details of why it went wrong. What should I have done ? Bring it immediately next time the same thing happens. I then pointed out that this meant waiting to be stranded and getting a tow truck. Yes, they replied. The very next day, that did in fact happen and I was towed all the way to the BMW dealership who then discovered that my model didn't have this download functionality as it was too old ... You can perhaps see why relying on a BMW's intelligence is not appealing ! (A further funny was with the BMW extra I bought in Germany to enable me to pre-warm the car before using it. You set a clock in the car to the time this pre-warming should start (using petrol from the tank) and it warms the motor and inside of the car until you get into it. This worked perfectly when the temperature was around zero but at a few degrees less refused to click into action - not much use in Finland then. On the other hand at temperatures at around +25 degrees Centigrade it did jump into operation when you were driving along (and were in desperate need of more heat, NOT !)! ) Mike Walsh, Helsinki, Finland email@example.com
Volkswagen has also thrown prudence to the winds in its rush to adopt high tech. We bought a 2002 VW Golf earlier this year, and within a week, the alarm system malfunctioned. The first symptom was the unprovoked appearance of the "open door" icon on the dash. The next symptom was the sounding of the alarm some time after locking the car in the normal manner - ie. by clicking the remote or turning the key in the driver's lock. The only way to prevent the alarm from going off was to lock the car manually, a procedure the misplaced confidence of the cars designers had made fiendishly difficult: 1. close the driver's door 2. lock all doors with remote 3. unlock the driver's door only with remote and reopen it 4. reach back to the rear door and unlock it with the handle latch 5. close the driver's door 6. open the rear door 7. reach forward from the rear and lock the front door by depressing the mechanical lock button 8. depress the mechanical lock button on the rear door and close it. This is the only way to lock the car without arming the alarm. Of course, the problem was intermittent. And the designers had not provided any diagnostics for the system. So on the first trip in to get the problem fixed, the dealership was unable to identify or solve it. The solution had to wait until the problem had escalated to the point where the hatchback could not be opened (in ANY manner! - there is no purely mechanical way to operate the hatchback latch). At this point the technicians' suspicion fell on the lock mechanism of the hatchback, which they then replaced, apparently fixing the problem. The potential problems are actually worse than appears from above, as the car has only two keylocks, that in the driver's door, and the one in the hatchback. The hatchback lock (when it's working) can only be operated by the battery-operated master key (the valet key won't work on it). So it would seem that if you have only the valet key and the driver's lock jams, there's no way to get into the car, other than breaking a window. Volkswagen supplies two of the master keys with the vehicle, and of these, the battery of one died in the first month. You're allowed to buy up to two more, but they cost more than CDN$200 each!
> The risks -- fail-safe modes must be carefully designed for the system > application: don't rely on the component default fail-safe mode. Surely, for them to fail any other way would be life-threatening? Okay, the prison needs an outer containment mechanism (and should have a backup generator), but if the power failed due to a fire within the prison, and all the doors failed locked, the prisoners would be trapped in their cells. Given the design of those cells, death due to smoke inhalation could happen extremely quickly - from what I've seen typical design is cells opening onto walkways round a central "courtyard" - this would fill with lethal smoke in short order, should the fire be in the accommodation block. (And don't forget, many prisoners may well be "innocents" awaiting trial...) Always think of the consequences of "safety" modifications. Like one incident I remember. An HSO demanded that a unprotected pulley belt be enclosed "for safety", despite the company concerned protesting most strongly that they'd never had anybody hurt, and it was a safety feature that it *wasn't* enclosed. Within months of doing as ordered, they'd had a serious accident, and the security housing was blamed in no uncertain terms as the cause of a minor incident turning into a major catastrophe. When one employee had an accident, his colleague had been unable to stop the machine by yanking the belt off the pulley, and by the time he'd run the length of the hall to the emergency stop button the trapped employee had been seriously injured.
[Stefanie Olsen, CNET News.com, 4 Apr 2002] Watch out--the spam choking your e-mail in-box may be loaded with software that lets marketers track your moves online, and you may not even be aware that you've been bugged. Web sites have long planted bits of code called "cookies" on consumers' hard drives to tailor Internet pages for returning visitors and better target ads. Now, enhanced messages that share the look and feel of Web pages are being used to deliver the same bits of code through e-mail, in many cases without regard for safeguards that have been developed to protect consumer privacy on the Web. "All of the security and privacy issues on the Web now relate to e-mail," said Adam Shostack, director of technology at Zero-Knowledge Systems, a Montreal-based privacy and security company. "The shame about this behavior is that it's going on surreptitiously and people are not given an obvious way to opt out." [...] http://news.com.com/2100-1023-875992.html
As a longtime spamfighter, I've learned to be a little careful about who gets my various e-mail addresses. If I wouldn't let someone call me collect... maybe they don't really deserve my personal e-mail address either. As a longtime human, I make mistakes. A few months back, for example, I submitted a piece to RISKS from... my personal e-mail address. Whoops. Now it's available on the web at no fewer than 8 URLs. Thus far, it's only gotten one piece of spam... I'll just hope other spammers and address-scraping 'bots are smart enough not to scrape addresses from a RISKS archive. Dan (using the correct address this time)
It seemed both appropriate and ironical to review Ray Bradbury's Fahrenheit 451 at this point in time. Earlier this month the US Congress began consideration of a bill that would ban the unauthorized reproduction of digital works. At almost the same time, federal prosecutors urged a court in Philadelphia to require technology in public libraries that would block access to information that some consider offensive. There is no kerosene dripping from the pages of books in Washington or Philadelphia, but digital words would not burn. The methods of eradication must be more subtle, the technique more sophisticated. It is tempting when reading Bradbury's classic work on censorship to draw parallels to book burnings from an earlier era, to make the obvious connection between the firemen in Bradbury's novel who set aflame houses that contained the printed word and those who gathered not so long ago to burn the words of Albert Einstein, Thomas Mann, Marcel Proust, Margaret Sanger, and H.G. Wells. But Fahrenheit 451 is not simply about book burning. This is a world where the culture of censorship has permeated the public and the private. There is no intellectual life. There is no political life. Interactive broadband technology provides endless entertainment through the full-screen images that appear on the walls of a parlor room. Words of meaning cannot be transmitted in any physical media. They must be memorized and passed on as they were before the printing press, before the written word. The protagonist Guy Montag, a fireman who will disavow his profession, confronts this reality in a series of encounters. First with a young woman who asks questions he cannot answer. Then with an old teacher who recalls a past that cannot be recorded. And finally with his boss, the Chief Firefighter who can quote Pope, Milton and Shaw, and then smile as a house and its contents are engulfed in flames. Montag's future is not without hope. He will fare better than Orwell's Winston, Kafka's K, or the Prisoner before Dostoevsky's Grand Inquisitor. Still, the reconstruction of culture, literature, and history once recorded words are banished cannot be assumed. When a single person can recall only one essay of Thoreau's or a chapter from Bertrand Russell, the unique quality of information -- its ability to flow without bounds -- is effectively exterminated. Perhaps it is unfair to compare the current legislative efforts to protect copyright interests or to prevent children from being exposed to images and words that are beyond their years with the unambiguous horror of burning a book because of the ideas contained inside. But technology does not make such distinctions, and capability creates opportunity. Already software filters have been turned on controversial ideas and unpopular organizations. And new copyright techniques will digitally incinerate recorded words that might otherwise be widely available. In this year when many city mayors are urging residents to share the experience of reading a common book, Los Angeles Mayor Jim Hahn has asked those in L.A. to read Fahrenheit 451. And Ray Bradbury's presence last week at a new mid-Wilshire bookstore, more than fifty years after the first publication of Fahrenheit 451, is a powerful reminder of the value of the written word. Marc Rotenberg http://www.epic.org/bookstore/powells/redirect/alert907.html
BKHKRCHL.RVW 20020221 "Hacker's Challenge", Mike Schiffman, 2001, 0-07-219384-0, U$29.99 %A Mike Schiffman %C 300 Water Street, Whitby, Ontario L1N 9B6 %D 2001 %G 0-07-219384-0 %I McGraw-Hill Ryerson/Osborne %O U$29.99 +1-800-565-5758 +1-905-430-5134 fax: 905-430-5020 %P 355 p. %T "Hacker's Challenge" Initially, I was skeptical of the title, considering the wording to be simply jumping on the current security bandwagon, with "hacker" this and "hacker" that on every bookshelf. In an odd way, however, the title is quite appropriate. This volume contains a series of twenty tests that are supposed to challenge your ability to analyze network data (most of the scenarios are network based) in order to identify and assess intrusions. Unfortunately, there are some problems in the implementation. The book is divided into two parts. First come the twenty scenarios, with varying types and degrees of detail about the problems. Then come twenty "solutions," which are supposed to point out how you should have approached the situation, and what indicators should have tipped you off to the intrusion and intruder. This physical division is rather meaningless: it isn't as if the solutions were short phrases that had to be printed upside down at the bottom of the page so that the reader doesn't inadvertently read the answer to the riddle while thinking about it. There is no reason that the solutions could not immediately follow the stories. Actually, the pieces were written by thirteen different authors, and the amount of detail varies tremendously. Therefore, all the possible mistakes that could be made in a work of this type are represented. Sometimes the audit logs presented to us in the scenario contain the relevant details and very little else, but the explanation is very sparse. In other pieces readers are presented with huge amounts of log data, and the relevant points are lost. There are scenarios which are not complete, and the data necessary to solve the problem is not given until the solution write-up. A few pieces contain almost no data for the reader in the problem section, while the solution presents almost no detection information or forensic exegesis. In one case we are given pages of log data and almost no analysis at all in the solution. There are articles that simply reproduce earlier situations with different characters. One solution makes no sense in terms of the data given in the problem outline. Some pieces are unclear, some simplistic, and some can only be described as misleading. The occasional scenario is written up almost poetically, and isolated solutions do have tutelary explanations of how to read network audit logs. If you are very good at forensic network analysis, you might enjoy pitting yourself against these challenges. Of course, if you are good at forensic network analysis you have more work than you can handle, and no time for games. If you are weak at network analysis, this book doesn't have very much to help you out. copyright Robert M. Slade, 2002 BKHKRCHL.RVW 20020221 firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer