Doug Maughan's Inside Risks column on the Cybersecurity Roadmap and the underlying security issues will appear in the Feb 2010 *CACM*. An html version is now up on my Inside Risks website: Douglas Maughan, The Need for a National Cybersecurity Research and Development Agenda *Communications of the ACM*, February 2010 http://www.csl.sri.com/neumann/insiderisks08.html#220 It includes hotlinks to the roadmap and various other relevant documents on the Department of Homeland Security Science and Technology cybersecurity website. (The roadmap document is currently the first item in the list.) http://www.cyber.st.dhs.gov/documents.html
Ars Technica reports (Jon Stokes, "How a stray mouse click choked the NYSE & cost a bank $150K," 27 Jan 2010): On November 14, 2007 at 3:20pm one of Credit Suisse's trading algorithms suddenly went haywire, and, in a few moments, sent hundreds of thousands of bogus requests to the exchange. This sudden surge of requests, which were cancellations for a large batch of orders that the machine had never actually sent out, acted like a denial-of-service attack on some parts of the New York Stock Exchange. The messages clogged the tubes and caused parts of the exchange to freeze up, affecting trading in 975 stocks. The article goes on to blame "a programmer [who] took it upon himself to unilaterally improve [the Credit Suisse program] by adding a new user input feature," which lacked "feedback and 'forgiveness'" and a lack of testing. On November 14, a few seconds after 3:20, a trader put a number in the box and then double-clicked the "up" arrow. This double-click was interpreted by SmartWB as two separate clicks, so the system dutifully sent out a second batch of cancel/replace orders in addition to the batch that was intended by the trader. This sudden flood of cancel/replace orders, half of which were requesting cancellation of orders that had never been sent, overwhelmed the system and backed up five of the posts on the NYSE trading floor. Without endorsing the programmer's impromptu improvement, it's fair to ask why a "flood" of bogus orders from a single bank would overwhelm the system. http://arstechnica.com/business/news/2010/01/how-a-stray-mouse-click-choked-the-nyse-cost-a-bank-150k.ars
I went to a talk today by a rather clueless Los Angeles company who is partnering with the Washington, DC, police in a number of efforts, many based on web-scraping. One of the things they're proud of is a (non-scraping) system that automatically delivers SARs ("Suspicious Activity Reports") to interested parties. For example, if an SAR has a location that's within 1000 feet of a university, they send a text to everybody's cellphone. They're at least a little bit clever; for example, for a big school they'll only contact the students living in the dorm(s) nearest the incident. OK, what's an SAR? Just about anything. If a little old lady sees a "suspicious man on the corner" (e.g., waiting for a taxi) and calls it in, that's an SAR. Obviously, in these fear-everything days, any forgotten package becomes an SAR-worthy possible bomb. About 300-400 SARs go out per day, though to be fair not every SAR goes to every person. When queried, they informed us that of course most SARs are bogus, but "three or four per year" are valid. Hmmm...300*365/4 = 27,375. That's a pretty impressive false-positive rate. They don't seem to see a problem with crying "wolf" that often. And one of their examples of a "true" positive was a political protest by Greenpeace, involving a not-very-dangerous stuffed polar bear. Nor do they seem to have thought about security and privacy issues. How do they protect their database of who lives in which dorm? Questions were cut off before I got a chance to ask that one, but I'm not optimistic. The RISK here is that everybody (developers and police) is so in love with the shiny technology that nobody stops to notice that the emperor has no clothes. Geoff Kuenning firstname.lastname@example.org http://www.cs.hmc.edu/~geoff/ [If you *can't* measure it, it's not science. Robert A. Heinlein, "The Door Into Summer"] [If you think you *can* measure it, something is probably wrong anyway. Peter G. Neumann, The ACM Risks Forum (Check your model and your assumptions at the door, eat a Heisenburger, and beware of many other risky challenges.)]
The Washington Metropolitan Transportation Authority, which runs the metrorail system in Washington, DC, has had exactly two accidents that killed customers in the 34 years it has been operating. From the system's opening in 1976 until 1982, there were no passenger fatalities. The first accident occurred when a derailed train was backed up, but the other half of the train had also derailed, crashing it into a tunnel abutment and killing 3 passengers. The accident happened on January 13, 1982, at the same time as the Air Florida Flight 90 crashed into the 14th Street Bridge. The second accident where 9 people were killed was in June, so if you average this, chances are either Metro won't kill someone until 2012, or, since each time they do have an accident, they kill 3 times as many, we could expect that since it was 6 years for the first accident, then 17 more for the second, that sometime around 2055, another Metrorail accident will kill 22 people! And it's this sort of estimation that actuaries use to figure out insurance rates. Given enough incidents you can do a pretty good job of figuring out how often you'll have claims. Actually, you're more likely to be killed on Metro if you're an employee than a customer, based on the number of employee deaths they've had. This also brings up a question: is the low number of customer deaths and long times between accidents a result of luck or some factors such as the equipment as designed being relatively safe?
Mostly affects military users, but also implications for some civilians. [TNX to Paul Saffo for spotting this one. (Robin Williams' Nanu-Nanu references probably unfamiliar to many readers.) PGN-ed] ``Moving Three GPS Satellites into New Orbits will have a profound effect on GPS capabilities for all civil, commercial, and military users worldwide.'' The GPS AEP Command and Control operational software update enables new capabilities ... but requires absolute compliance with the published GPS Interface Control Document (ICD). Some of the new features that are incorporated work only with authorized military receivers that have successfully passed security tests. However the live introduction of the new functions is causing problems wherein some of these receivers are intermittently not tracking Y-code, and non-compliant civilian receivers are also reporting continuing problems. Corrective action could encompass either the Air Force rolling back the update or revising its software, or the manufacturers modifying GPS software within the receivers to be totally compliant with the ICD. January 21, 2010 http://www.gpsworld.com/gnss-system/news/gps-control-software-glitch-nanu-issued-9414 http://www.gpsworld.com/gnss-system/news/new-243-gps-configuration-will-increase-accuracy-9368
"Verified by Visa and MasterCard SecureCode: or, How Not to Design Authentication" by Steven J. Murdoch and Ross Anderson <http://www.cl.cam.ac.uk/~rja14/Papers/fc10vbvsecurecode.pdf>: Banks worldwide are starting to authenticate online card transactions using the `3-D Secure' protocol, which is branded as Verified by Visa and MasterCard SecureCode. This has been partly driven by the sharp increase in online fraud that followed the deployment of EMV smart cards for cardholder- present payments in Europe and elsewhere. 3-D Secure has so far escaped academic scrutiny; yet it might be a textbook example of how not to design an authentication protocol. It ignores good design principles and has significant vulnerabilities, some of which are already being exploited. Also, it provides a fascinating lesson in security economics. While other single sign-on schemes such as OpenID, InfoCard and Liberty came up with decent technology they got the economics wrong, and their schemes have not been adopted. 3-D Secure has lousy technology, but got the economics right (at least for banks and merchants); it now boasts hundreds of millions of accounts. We suggest a path towards more robust authentication that is technologically sound and where the economics would work for banks, merchants and customers -- given a gentle regulatory nudge.
Radiation Offers New Cures, and Ways to Do Harm The New York Times, January 23, 2010 http://www.nytimes.com/2010/01/24/health/24radiation.html This article goes into some detail about several failures in radiation treatments which lead to severe injury and deaths in patients. Although there was substantial human error involved, it seems that in some cases computer crashes and lack of failsafe functionality were at least contributing causes. In one example, a crash of the controlling computer led a technician to mistakenly believe that instructions to properly restrict the amount of radiation received were saved, when in fact they were not. This was then compounded by additional error as operators failed to manually check whether the settings were correct. The patient was then massively over-radiated on several occasions. I wonder if the general flakiness in personal computers that we are all used to results in an attitude that accepts such things as normal and acceptable, even in people who should have been trained to know better, and possibly even product designers and managers. In this example, such an attitude would probably have worse consequences than the actual technical fault in the equipment.
Ever worry that that gadget you spend hours holding next to your head might be damaging your brain? Well, the evidence is starting to pour in, and it's not pretty. So why isn't anyone in America doing anything about it? [Source: Christopher Ketcham, February 2010 issue of *GQ*, PGN-ed] http://www.gq.com/cars-gear/gear-and-gadgets/201002/warning-cell-phone-radiation
[The article emphasizes that it was a porn movie being watched, but it seems to me that the result could easily have been the same for many other genres -- WDR] State police say a truck driver was watching pornographic movies on his laptop computer when his rig struck a disabled car on the New York State Thruway near Buffalo last month, killing the driver. Thomas Wallace of Ohio was arrested Tuesday. He's been charged with second-degree manslaughter in the death of 33-year-old Julie Stratton, a mother of two from a Buffalo suburb. [...] Investigators say Wallace also violated federal trucking rules by sleeping no more than four of 27 hours before the crash. http://cnews.canoe.ca/CNEWS/World/2010/01/27/12640006-ap.html
To go home from the Washington DC Metro I take either the 83 or 86 Metrobus into Maryland. The difference between the two routes is that the #86 takes a detour into the Prince George's Plaza station. There is a street that crosses both routes. On the #86, the bus turns off Baltimore Ave and eventually reaches 40th Avenue, turns onto Oglethorpe street, where it turns on 42nd Ave. On the 83, it continues on Baltimore Ave and simply crosses Oglethorpe. However, on board every bus running on the 83 and 86 lines is a display that shows to the passengers every street where the bus is making. It is consistent, in that on every #86 bus, it indicates when it is at *Oglethorpe Street*. On every #83 bus, it indicates when it is at *Ogelthorpe Street*. Maybe it's just a GSP, err I mean GPS error...
Near where I live in Zurich, Friedackerstrasse meets Friedheimstrasse in a T intersection. But Google Maps and the street map overlay in Google Earth show Friedackerstrasse making a 45-degree angle there. The canopy of a tree at that intersection overhangs the entire actual meeting point of the two streets, something perfectly evident to the human eye in the aerial photograph. I hazard the guess that software used to detect roads on aerial photographs simply lost the streets there because of the tree, leaving the algorithm to do something -- anything -- about that, using some additional GIS data indicating that the streets really do intersect. And the algorithm routed (the mapping of) Friedackerstrasse through the house on the northeast corner. (It also routes a nearby pedestrian walk squarely through the apartment building it abuts.) In practice this one case isn't a large risk because you can't really get lost because of it, but it provides some insight into how the software works, and how it fails when it fails. Where else are streets re-routed, nonexistent segments added, or existing ones omitted? And other features? It's not hard to imagine how this might be important. This error, combined with the (here well known) principle "there's never just one bug", must give us pause.
Actually this is a user error. Opera Mini uses transcoding to present the web page on mobile devices. That means every single bit transmitted and received is processed through Opera's computers. That's the reason for the Norwegian IP address. Gary should have paid a few bucks for Opera Mobile which does not use transcoding, relying on more traditional on-device html interpretation. I spent quite a bit of time testing both versions. Opera Mini is, indeed, very fast, but it always struck me that users were giving up way too much privacy. Tony Lima Associates, Los Altos, CA, USA, 650-243-1286
When the Shuttle overflies the runway when returning from the next ISS mission, we'll know why. Mark Jackson - http://www.alumni.caltech.edu/~mjackson
Please report problems with the web pages to the maintainer