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…
I was just reading a great article on the need for a Smart electric Grid at http://www.sciam.com/article.cfm?id=preventing-blackouts-power-grid but found myself hoping that the people designing it are Risks readers. Running the grid on a fly-by-wire system, and getting better efficiencies out of it by running it closer to the edge of stability are pretty scary concepts for long-time Risks readers. The thought of replacing every device (switch, circuit breaker, etc.) with a computerized version makes my brain want to explode. Not that it _can't_ be done, any more than the ATC system can't be upgraded, but exhortations to do so make me want to ensure I'm current on my generator maintenance.
Saul Hansell's blog, How Wall Street Lied to Its Computers, 18 Sep 2008, http://bits.blogs.nytimes.com/2008/09/18/how-wall-streets-quants-lied-to-their-computers/?pagemode=print I called some old timers in the risk-management world to see what went wrong. I fully expected them to tell me that the problem was that the alarms were blaring and red lights were flashing on the risk machines and greedy Wall Street bosses ignored the warnings to keep the profits flowing. .... But she and others say there is more to it: The people who ran the financial firms chose to program their risk-management systems with overly optimistic assumptions and to feed them oversimplified data. This kept them from sounding the alarm early enough. a) In other words, "Tell ourselves what we want to hear..." b) Quis custodiet ipsos custodes
Saul Hansell, writing his *The New York Times* blog on 18 Sep 2008, offered a detailed account of how the mortgage loans crisis was due to wishful thinking in the entry of data to the automated tools bankers now count on to warn them of risky loans. While the principle of "Garbage In, Garbage Out" is old news to RISKS readers, I thought this article was a useful reminder that the risks of GIGO still has not penetrated to the general public. http://bits.blogs.nytimes.com/2008/09/18/how-wall-streets-quants-lied-to-their-computers/?em
Continuing the saga re: BNY Mellon noted in RISKS-25.31, earlier reports indicated that perhaps 200,000 Massachusetts consumers and 4.5M people nationwide may have been affected. The corrected numbers now exceed 400,000, in Massachusetts and 12,000,000 nationwide according to the NY state Attorney General Martha Coakley. [Source: Jonnelle Marte, Bank's data loss may hit 400,000 Mass. customers, *The Boston Globe* online, 19 Sep 2008; PGN-ed] http://www.boston.com/business/articles/2008/09/19/banks_data_loss_may_hit_400000_mass_customers/
*The Boston Globe*, 17 Sep 2008: "_Bottom to crisis nowhere in sight_. The root of the panic on Wall Street is that investors have lost $350 billion from their securities backed by subprime mortgages. But on top of that, Wall Street holds tens of trillions in other arcane securities that were based on these mortgages. These mortgage securities are so complex that it's hard to calculate the value of these investments because owners do not clearly disclose their holdings. As a result, analysts and economists can't grasp how widespread the problem is... [A professor said] 'You know there are securities linked to the value of mortgages. You don't know how much those securities are worth...' Any attempts to gauge the size of these markets are 'an estimated guess,' said [an analyst]. 'When you zero in on the number, we don't know what the real risk is in there. It could be small or large. We just don't know," he said. "It's breathtaking.' [An economist said] 'it's hard to figure out who owes what to whom, and when that becomes a problem, markets don't function properly.'" "Wall Street firms... packaged mortgages together in pools, issued securities backed by the pools, and then sold them to investors. In addition, they created and traded complex securities known as 'credit default swaps...' The insurance contracts form an unseen but tangled web of connections linking AIG and Wall Street investment banks to hedge funds and even countries that invested in them. They are also one item in a smorgasbord of similar contracts - many of them based on corporate debt, credit cards, automobile loans, and commercial property loans - that is an unfathomable $63 trillion." Plenty of blame to go around, but where do computers come in? Data processing made it possible to manage mutual funds with more than a few dozen stocks in them, like the first S&P index fund. Computer networking made it possible to interconnect financial products from different companies and create multilevel financial products, like Fidelity's Dynamic Strategies Fund. This "fund of funds" invests, not in stocks, but in other mutual funds and ETFs... _over a hundred of them_. What would happen if you asked Fidelity for an inventory of the certificate numbers of all of the stocks in that fund? Computer technology made it possible to build multilevel pyramids of financial products. These products contain many so investments, all many steps removed from the product's owner, that the owner cannot possibly have an intuitive grasp of them, or make any kind of reality check on their risk. They are so distant from the actual investments that underlie them that last November a federal judge in Ohio dismissed 14 foreclosure cases brought on behalf of mortgage investors, because the investors were unable to prove they actually owned the properties. I once considered driving out to take a look at one of the commercial properties whose address was listed in the TIAA Real Estate Fund's quarterly report, just to see whether it was really there. I doubt that such a thing has even crossed the mind of the people who trade credit default swaps. It might turn out that, without anyone really noticing, the global financial system has gradually turned into something that is mostly a MMORPG.
Re: Automated Bill Payments Are a Cinch: Not So Fast, Erling Kristiansen (RISKS-25.32) It should be statistically practically impossible to accidentally enter a valid account number. If account numbers have no check digits, the bank has made a fundamental design error. I have been living in Amsterdam now for four months (previously I lived in the UK). In the UK, my banks accounts are described by an eight digit account number and a six digit sort code (I believe this is true for all UK banks). There are no check digits, but the account number must match the sort code, which provides a useful validation. In Holland, an account with ABN AMRO is described by a single nine digit number. There are no check digits. If you enter the wrong number, the bank will accept it, since it cannot detect your mistake.
Four months ago, I emigrated from Cambridge, England to Amsterdam, Holland. Emigration requires at the destination the resumption of the organised necessities of life - such as, for example, a bank account. There are three main banks in Holland - ABN AMRO, Postbank and Rabobank. (My commiserations to any banking entity not making my list). On the basis of an almost nonexistent set of reviews for these banks and their services, I chose ABN AMRO. Fast-forward nearly four months to this most recent weekend. I unfortunately suffer from a hopefully transient neurological deficit which means my working memory is seriously impaired. (Something that happens naturally, it seems to me, to people as they move toward the slower realms of advancing age, so I think I am not alone in this deficit.) As such, I forgot my Dutch PIN. I wanted to phone ABN AMRO, to ask them to change my PIN. Unfortunately, where the rental market is Amsterdam is nonexistent (State intervention in the market has eliminated the market), I have not yet settled into a place of my own and so do not have a fixed land line - only a Dutch SIM mobile. ABN AMRO offer two customer service numbers; one for use inside Holland, one for use internationally. The internal number cannot be called from my mobile. I do not know why. The international number detects you are calling from Holland and after a short, polite, Eddiesque message - "you're calling from Holland! I have to disconnect you immediately! share and enjoy!" *click* - and so I cannot phone the bank. This is of course a risk; don't needlessly eliminate redundancy in your systems. So, I have to travel, physically, to a branch. Fortunately, I'm young and healthy in body and traveling is not an issue. I arrive at the bank — on Saturday, naturally, since I do not wish to take a day off work just to visit. I queue for a while. Dutch banks like that. I'm eventually approached by a Rutger Hauer look-a-like. I ask to change my PIN. "Oh no, no...you're thinking you can change your PIN? no." "I can't change my PIN? but then how do I make my card work again?" "All we can do is issue you a new card. It takes three days. There's a charge." I note in the UK, card issuing is free and you can change your PIN over the phone. Perhaps if card issuing here was free, you would also miraculously suddenly be able to change your PIN. "Well, I need some money now - I don't have any cash on me and I need to do shopping and I can't use my card." "Oh no, no...you're thinking you can withdraw money? no." "I can't withdraw MONEY?!?" "Not on the weekend. You have to come during the week. To this branch or one of two others in Amsterdam. No other branches provide money. And no branches provide money on the weekend." (At this point, Rutger was looking at me as if I was slightly insane. Clearly, I had picked up in the UK some dangerous Anglo-Saxon notions of banking service, along the lines of being able to withdraw my money from my account). "Look, I need to pay my rent. Can I transfer some money?" "Oh no, no...you're thinking you can transfer money? no." "I can't transfer money!?" "No. You can only transfer money on-line and you must have your card and PIN. Also, there's a charge." "So...I can't withdraw money and I can't transfer money?" "That's right." (I looked around, warily, to check I had not fallen into a re-enactment of The Castle and was being mistaken for the protagonist. Alas, it was just an ABN AMRO branch.) "Okay, let me think...okay - if I closed my account, it has money in it now, what would happen to that money? you'd have to send it somewhere?" "Yes. If you close your account, we will transfer the money to the account you specify. It'll take a few weeks." "A FEW WEEKS??!?!?" "Yes. The account is closed immediately of course, but there are checks and so on that we need to do. There is much bureaucracy that must be done. It takes a few weeks before the money is transfered." At this point I realised that I was reflexively clenching and unclenching my fist and it seemed a prudent time to depart, lest the headlines -- "Embittered AMRO customer slays ten in money withdrawal horror!" "AMRO says -- we never expected people to forget their PIN!" RISKS? single point of failure upon an entirely plausible failure mode (losing the PIN) with no fallback behaviour. If for any reason you forget your PIN, you can find yourself absolutely shut out of your account -- unable to withdraw money, unable to transfer money and even closing the account, the final recourse, is arranged such that your funds are sequestered. You literally have no access to your money. Like most people, I need to eat and get grumpy when I'm starved for two days. Furthermore, I now have the choice of paying a charge for a new card, which I will use exactly once, to transfer my funds to my new Rabobank account before closing my ABN AMRO account, or actually physically withdrawing a couple of thousands euros and *walking* it across to my new bank to deposit it. BTW, depositing cash into a Dutch bank? there's a charge.
A web search for SECURE.UNINITIALIZED.REAL.ERROR.COM shows that this is neither phish nor phowl, it's a bug, not a pheature, though perhaps a bug most phoul. Apparently an error message about an uninitialized variable is being substituted where a URL is supposed to go in a template for the e-mails. This has been happening at least for almost a year. http://www.tamebay.com/2007/10/genuine-paypal-emails-with-spoof-urls.html Luckily whoever owns error.com has not set up a phishing website to take advantage of the bug. But the bug may not be as benign as simply producing a bogus URL in the e-mail. This report indicate that it may be associated with PayPal transactions that the user aborts being completed anyway: http://discussionboard.prostores.com/showthread.php?t=7795 This one is even worse. Not only does it seem to be associated with a bogus charge to the PayPal account, but it demonstrates the bug showing up as bad links in e-mail from a presumably live PayPal customer service representative sent to a customer: http://forum.skype.com/index.php?showtopic=192431 Sidney Markowitz http://www.sidney.com
I'm surprised no-one has mentioned the Direct Debit scheme which operates in the UK, mostly very successfully; "Over 75% of adults in the UK have at least one Direct Debit and around 100,000 organisations use Direct Debit for collecting a variety of regular and occasional bills including utility payments, insurance, council tax, mortgages, loans and subscriptions." http://www.bacs.co.uk/BACS/Consumers/Direct+Debit/ The "Direct Debit Guarantee" covers your rights; "If an error is made by the organisation or your bank or building society, you are guaranteed a full and immediate refund from your branch of the amount paid." To our (UK) eyes, US retail banking is very old-fashioned (*). I haven't written a cheque (US: check) for a utility bill (or any other regular payment) for years. Indeed, cheques are fading from use at an accelerating rate and a number of large organisations no longer accept them. Cheque processing was out-sourced by most UK retail banks some years ago as no longer economic to keep in-house. (* Given recent events, I am no longer sure if this is a good or bad thing.)
Of course, it's being sold as a plan to Protect The Chilluns: http://www.thenewspaper.com/news/25/2537.asp Private companies in the US are hoping to use red light cameras and speed cameras as the basis for a nationwide surveillance network similar to one that will be active next year in the UK. Redflex and American Traffic Solutions (ATS), the top two photo enforcement providers in the US, are quietly shopping new motorist tracking options to prospective state and local government clients. Redflex explained the company's latest developments in an August 7 meeting with Homestead, Florida officials. "We are moving into areas such as homeland security on a national level and on a local level," Redflex regional director Cherif Elsadek said. "Optical character recognition is our next roll out which will be coming out in a few months — probably about five months or so." The technology would be integrated with the Australian company's existing red light camera and speed camera systems. It allows officials to keep full video records of passing motorists and their passengers, limited only by available hard drive space and the types of cameras installed. To gain public acceptance, the surveillance program is being initially sold as an aid for police looking to solve Amber Alert cases and locate stolen cars. I don't, at the moment, see any way around this problem: corporations are in it only for the money; if they can make that money by selling to governments capabilities that it would be illegal for the governments to implement on their own, they will. It's a slippery slope, in the reverse of the usual direction. And remember: if that database exists, your wife's divorce attorney will be able to subpoena it. Nice to know Al Queda doesn't need to take away our freedoms; like the citizens of the Weimar Republic, we're doing a bang up job of it ourselves. Jay R. Ashworth, Ashworth & Associates, St Petersburg FL USA 1 727 647 1274 Baylink http://baylink.pitas.com email@example.com
All Nippon Airways (ANA) made a public announcement on September 19, 2008 that the check-in system trouble for the domestic flights happened on September 14, 2008 was caused by expiration of the cryptographic certificate issued for access authentication of check-in terminals for the ticket agents. The company told that: * the certificate was expired on September 14, 2008; * the expiration was direct cause of the errors of the check-in terminals when the terminals were booted on September 14, 2008; * the company knew when they first installed the certificate on 2005; * they didn't activate the certificate until September 2007; and * no one in the company did notice the expiration during the development of the terminal subsystem. Sources: ANA public announcement (in Japanese) http://www.ana.co.jp/topics/notice080914/index.html The risks are obvious: * If you depend on something which will expire, such as PKI certificates and domain name subscription, failure of the renewal may kill the whole subsystems depending on the expired objects; * If you depend on something which will expire, a warning system (of pre-expiration notice) should be installed to tell you about the expiration, or you will forget about it and may cause the system trouble; and * You should always be aware of the *unused* functions of a system and how they work, especially when you decide to activate some of them.
Self-evidently, fitness for purpose should trump cost of development in this discussion, because the incremental cost of carrying out the final stage of development (and then operation) in an environment that does not require the system to include its own protection against virus infection is fairly small, and the examples that have been given describe systems that are clearly not fit for purpose as implemented. On the other hand, if cost is more important to you than fitness for purpose, I have a system waiting for you that costs 10% less than the lowest estimate anyone else has given you. Give me a call. Martyn Thomas CBE FREng http://www.thomas-associates.co.uk
Aurora is US Gov name for the mischief hackers' malware can do when targeted directly at electric utilities. Here's a link to a couple of recent Aurora incidents: (a) $ 1 million generator blown up by hacking = DHS proof of concept. (b) Vancouver Canada insider crime as union negotiating http://www.militaryphotos.net/forums/showthread.php?t=121081 US Congress hearings last week into what it takes to protect against this. (a) Public Utilities complain that by US making Aurora details top secret, even from their industry, they cannot mitigate against all threats known to gov. (b) US gov agencies say solution is for Congress to give them unfettered authority to meddle in industry, with zero accountability for how that authority is used. Here's a link to those hearings. http://energycommerce.house.gov/cmte_mtgs/110-eaq-hrg.091108.Cybersecurity.shtml
The problem with commands like $ sleep 666; destroy_planet is that Dr. Evil can type them on your VT100 terminal and walk gleefully away, while you try to find the bash page in the manual racks to see if there are any safe control or break keys you can press short of yanking the terminal out of the wall as time runs out... but it was all a bad 1980's dream, as the librarian tugs your shoulder "Sir, your half-hour is up and there are a lot of people waiting to use a terminal."
This is standard behavior on most amateur radio transceivers, because there are many more functions needed than there are keys on the device. One of my transceivers (Yaesu FT-8100R, a mobile 2-meter/70-cm unit) triples up on some keys: 1. Press the key to activate the Normal function. 2. Press the F/M key (similar in concept to a shift or control key) and then press the key to activate the Alternate function. 3. Press the F/M key for 1/2 second or more and then press the key to activate the Super-Alternate function. I have memorized some of the Alternate functions, but I usually have to refer to the manual for the Super-Alternate functions. [Incidentally, in RISKS-25.34, Sergei apparently completely missed the humor that Mark Brader had very amusingly noted ("to be held down"), which my comment highlighted to make sure our readers did not miss it. However, Sergei apparently did miss it. I seem to have compounded the silliness by evidently oversimplifying the repetition of the gaffe that Mark quoted by trying to correct it, because Sergei had responded not to the humor that had amused Mark and that had inspired me to run Mark's item in the first place. If that perhaps mistakenly gave anyone the impression that Mark would have disagreed with Sergei, I profoundly apologize to Mark. This is a case where the humor should have been obvious to readers of Mark's item in RISKS-25.32, not the details of the implied corrected statement. PGN]
2009 USENIX Annual Technical Conference June 14-19, 2009, San Diego, CA Paper Submissions Deadline: January 9, 2009, 11:59 p.m. PST http://www.usenix.org/usenix09/cfpb/ On behalf of the 2009 USENIX Annual Technical Conference program committee, we request your ideas, proposals, and papers for tutorials, refereed papers, and posters. Authors are invited to submit original and innovative papers to the Refereed Papers Track of the 2009 USENIX Annual Technical Conference. Papers can be either full papers of at most 14 pages or short papers of at most 6 pages. Authors are required to submit papers by 11:59 p.m. PST, Friday, January 9, 2009. (Note new deadline.) In full papers, we seek high-quality submissions that further the knowledge and understanding of modern computing systems, with an emphasis on implementations and experimental results. Short papers should describe early ideas, advocate a controversial position, or present interesting results that do not require a full-length paper. We encourage papers that break new ground or present insightful results based on practical experience. The USENIX conference has a broad scope. Specific topics of interest include but are not limited to: --Architectural interaction --Cloud computing --Deployment experience --Distributed and parallel systems --Embedded systems --Energy/power management --File and storage systems --Mobile, wireless, and sensor systems --Networking and network services --Operating systems --Reliability, availability, and scalability --Security, privacy, and trust --System and network management and troubleshooting --Usage studies and workload characterization --Virtualization --Web technology More information on these and other submission guidelines is available on our Web site: http://www.usenix.org/usenix09/cfpb/ On behalf of the 2009 USENIX Annual Technical Conference organizers, Geoffrey M. Voelker, University of California, San Diego Alec Wolman, Microsoft Research 2009 USENIX Annual Technical Conference Program Co-Chairs firstname.lastname@example.org
Please report problems with the web pages to the maintainer