RISKS-LIST: Risks-Forum Digest Sunday 24 May 2009 Volume 25 : Issue 69 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <http://www.risks.org> as <http://catless.ncl.ac.uk/Risks/25.69.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: Another Boston subway crash with cell-phone implications HIV patients sue after records left on MBTA (Elizabeth Cooney) NZ bank lends $10M instead of $10K; couple takes the money and runs (Ian Wells) Re: NY voter voted absentee, then died; ballot ruled invalid (Paul Wallich, Harvey Fishman) Fragility of telephone system (Jim Haynes) SANS NewsBites gets it very wrong, fails to post a correction (Jonathan Kamens) Re: Nielsen Ratings (Rupert Moss-Eccardt) How to make memorable but secure passwords (Phil Colbourn) Re: A Lesson in Internet Anatomy: The World's Densest Meet-Me Room (Jidanni) Re: FAA ATC shutdown (Walter Roberson, Chris Drew, Gene S. Berkowitz, Al MacIntyre, Fred Cohen) Re: On Government IT competence (Pete Kaiser) eCrime Researchers Summit CFP (Monty Solomon) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sat, 23 May 2009 20:52:13 PDT From: "Peter G. Neumann" <neumann_at_private> Subject: Another Boston subway crash with cell-phone implications At 7:18pm on 8 May 2009, one inbound subway train rear-ended another train in the Green Line in the Boston MBTA at 25 mph. The driver of the offending train (24-year-old Aiden or Aidan Quinn [both spellings appear in the same article from the *EDGE*], who reportedly had three auto speeding violations) was allegedly texting his girlfriend at the time. 49 passengers were injured and taken to the hospital, and three cars were crushed. This incident followed another similar case in 2008 in which another driver had allegedly been on her cell phone just before that train collided with the preceding one. [Source: PGN-ed from various news reports. Please browse the Web if want some of the background, which is way beyond the scope of RISKS.] ------------------------------ Date: Sat, 23 May 2009 23:36:12 -0400 From: Monty Solomon <monty_at_private> Subject: HIV patients sue after records left on MBTA (Elizabeth Cooney) Four HIV-positive patients whose records were left behind on an MBTA train by a Massachusetts General Hospital employee are suing the hospital, contending their privacy was breached. In March 2009, the hospital notified 66 patients who received care at its Infectious Disease Associates outpatient practice that billing records bearing their names, Social Security numbers, doctors, and diagnoses had been lost by a manager who was riding the Red Line. She had brought the paperwork home for the weekend, but left it on the train when she returned to work Monday morning, March 9, according to a hospital security report. [Source: Elizabeth Cooney, HIV patients sue after records lost; Hospital worker left files on MBTA, *The Boston Globe*, 21 May 2009] http://www.boston.com/news/local/massachusetts/articles/2009/05/21/hiv_patients_sue_after_records_lost/ ------------------------------ Date: Sat, 23 May 2009 16:40:51 +1200 From: Ian Wells <familywells_at_private> Subject: NZ bank lends $10M instead of $10K; couple takes the money and runs It is not public yet how this error occurred. Couple is being charged with fraud, who decided to be fugitives when a bank error gave them a $10,000,000 loan instead of $6,000,000. http://www.stuff.co.nz/national/crime/2428243/Couple-missing-after-10m-bank-bungle Ian Wells, Christchurch, New Zealand ------------------------------ Date: Sat, 23 May 2009 21:16:39 -0400 From: Paul Wallich <pw_at_private> Subject: Re: NY voter voted absentee, then died; ballot ruled invalid (R-25.68) It gets even more complicated than that. In some jurisdictions, one actually votes during early voting (at a machine or with whatever other tools the site uses), while in others one fills out what is effectively an absentee ballot and hands it to the clerk for storage until election day. (In the latter case, there's a double envelope, with the inner one unmarked and the outer one signed and named, and the name used by the clerk to cross a voter off the main register.) So someone who voted early by machine and then died would have their vote count, whereas someone who voted by the accurately but oddly-named in-person absentee ballot could in principle be culled. Here's a case where reusing existing methods for a new purpose actually improves accuracy compared to inventing new methods. ------------------------------ Date: Sat, 23 May 2009 21:06:37 -0400 (EDT) From: Harvey Fishman <fishman_at_private> Subject: Re: NY voter voted absentee, then died; ballot ruled invalid (R-25.68) > [Source: Tiebreaking Vote Cast by Dead Man; Runoff Required, AP item, PGN-ed. I do not believe that we have in-person early voting in New York State. Certainly we do not have it in New York City (understandably, as polls are generally in places like schools which are dedicated to other uses except on election days), but I only assume that voting rules are state-wide. [Yes. PGN] ------------------------------ Date: Sat, 23 May 2009 20:52:23 -0500 (CDT) From: Jim Haynes <jhhaynes_at_private> Subject: Fragility of telephone system It's now been a while since the fiber optic cable cuts in the S.F. Bay Area. I've been waiting for an explanation of why cutting 3 or 4 fiber cables completely killed telephone service in all or part of three counties. ------------------------------ Date: Sat, 23 May 2009 23:17:45 -0400 From: Jonathan Kamens <jik_at_private> Subject: SANS NewsBites gets it very wrong, fails to post a correction I thought the following might be of interest to RISKS readers, both because I'm sure many of us also read (http://www.sans.org/newsletters/newsbites/) SANS NewsBites, and because this deals with misrepresenting computer-related risks in a very real way. In a recent NewsBites issue (11.39), the following item appeared as the headline story: >TOP OF THE NEWS > --One In Five Teenagers Claim to Have Used Hacking Tools >(15th May 2009) >A recent survey of 4,000 teenagers between the ages of 15 to 18 years >of age states that 17% of those surveyed know how to find hacking tools >online with one third of that group admitting that they have used the >tools.... In this little blurb, the editors of SANS make two statistical errors, one small and one very, very large. Here's the actual press release contents: "The survey also revealed that 17 percent of adolescent users claim to have advanced technical knowledge and are able to find hacking tools on the Internet. Of these, 30 percent claim to have used them on at least one occasion." The minor error is that 30% is less than one third. While a 3.33% difference might seem insignificant, it's little "telephone-game" changes like this that over time result in seriously divergences from reality. Note that one of the articles which SANS cited used the phrase "nearly a third," which is accurate, and SANS apparently saw fit to drop the "nearly." The second, much more serious error, is that the percentage of teenagers who admitted that they have used the tools is not "one in five," but rather 30% of 17%, which comes out to 5%, or ONE IN TWENTY, a huge difference from what SANS reported. I emailed the editors of SANS the same day this issue came out, pointed out both errors, and asked them to post a correction. The next issue was published three days later with no correction included. This is rather unfortunate. I find it just a bit disturbing that none of the editors of NewsBites, supposedly experts in the field, found the "one in five" statistic sufficiently surprising to dig deeper and discover the truth of the matter. I certainly did. ------------------------------ Date: Sun, 24 May 2009 08:35:33 +0100 From: Rupert Moss-Eccardt <r.moss-eccardt_at_private> Subject: Re: Nielsen Ratings (RISKS-25.68) I must say I was surprised to see the assertion that the Nielsen server failures were directly attributable to the outsourcing. Firstly, I thought this was a moderated list and the assertion is a rather bald one. Secondly, and this is more of a risk, it appears from this and the comments posted to The New York Times article referenced that the real problem was that Nielsen had a set of systems with no real business continuity. According to former staff, if the comments are to be believed, the systems were fragile enough to be prone to failure if not cared for in special ways that weren't documented fully, or at all. [Rupert, Many TNX for the comment. PGN] ------------------------------ Date: Sun, 24 May 2009 20:42:51 +1000 From: phil colbourn <philcolbourn_at_private> Subject: How to make memorable but secure passwords Some people, perhaps most, have a system for making passwords. Some systems involve the use of the same password everywhere - easy to remember but if discovered their online life is easily accessed. Others have different passwords and write them down. My system is to maintain long, virtually unique passwords which I never need to commit them to paper or electronic note. My goals are: * at least 8 characters * the use uppercase, lowercase, digits and symbols/punctuation * the discovery of the system should not compromise my passwords * no need to record any password * be able to quickly work-out my password for any site The System * Make up a memorable code with preferably uppercase, lowercase, numbers and symbols/punctuation. * For each site, consistently use some aspect of the site such as 3 or 4 letters/numbers of the site URL - modified in some systematic way - and add it to your memorable code. Add it using any rule you like. There is a problem with this system: sometimes sites change their name which, for me, has happened once. In this case I have not needed to change my password but since most sites will send your password to you, should you forget, you can easily have your old password recovered and then you can change your password - it doesn't happen often. Examples Assume your memorable code is Ab19#z. Example 1: Use the first, second, second-last and last characters of the site, added in reverse order, first and last capitalized, insert after the 4th character of your memorable code. So a password for google.com would be Ab19EloG#z. And for ibm.com it could be Ab19MbbI#z. (You should have some way to handle site names that 'fail' your system or require longer passwords than that of your system). Example 2: Insert the memorable code into the first and last characters of the site name. So the password for google.com would be gAb19#ze. It goes without saying (hopefully) that you should make up your own system and you should probably not use my examples. Ideas: * Consider using the organisation type or country code. * Consider using multiple systems. One for important sites and a simpler system for ad-hoc, single-use and other sites not containing personal data * Consider a version of the system for your home PC accounts Your should assume that your system could be discoverable, so you need to choose a memorable code that is secure by itself. If you want to document your system, do so with care. You should not write it down verbatim - try to obscure it ;-) ------------------------------ Date: Sun, 24 May 2009 21:17:20 +0800 From: jidanni_at_private Subject: Re: A Lesson in Internet Anatomy: The World's Densest Meet-Me Room "without incurring local loop fees" mentioned in http://en.wikipedia.org/wiki/Meet-me-room is a factor encouraging putting so many eggs in one basket Re: http://catless.ncl.ac.uk/Risks/25.68.html#subj5.1 ------------------------------ Date: Fri, 22 May 2009 14:35:51 -0500 From: "Walter Roberson" <roberson_at_private> Subject: Re: FAA ATC shutdown (Kaiser, RISKS-25.67) Pete Kaiser, in suggesting reasons why IT might be bad in government, including the possibility of "where underfunded entities are asked to perform miracles on inadequate budgets". I used to be a systems administrator for a government (outside the USA) in an underfunded situation. I instrumented and measured and compared published Fortunate 500 surveys: our 2/3-person equivalent networking staff was achieving uptimes slightly better than the average 12-person dedicated network staff reported for the F500 companies -- and was doing so with equipment that was mostly already declared End Of Life by the respective manufacturers. We worked, underfunded, in government, but we were quite dedicated -- as were the co-workers in other sites that I interacted with. ------------------------------ Date: Sat, 23 May 2009 22:37:02 +0100 From: "Chris Drew" <e767pmk_at_private> Subject: FAA ATC shutdown & Gov't IT Competence (Kaiser, RISKS-25.67). > Businesses have many ways of concealing their IT incompetence that aren't > available to government, especially the option of simple secrecy; and we > write our laws to protect (if not always guarantee) their ability to make a > profit even when they screw up. Yebbut... As I see it from a UK perspective: * If a company's IT project is ineffective or costs too much it will damage the company financially and may even put it out of business. In the case of a Government IT project, it can throw taxpayers' money at it until it either works, sort-of, or it is quietly abandoned (or dies of shame). * If a company's customers or suppliers feel that the company is storing or using their information improperly, they can take their business elsewhere. Citizens don't have any choice about dealing with and handing data to the Government. * If a company's IT project violates laws concerning, say, data protection or security of storage, then the company will likely find itself in big legal trouble. If a Government IT project is illegal..? Well there may be some sound and fury, but that's as far as it goes (e.g. "Private details/UK Government disks" saga, RISKS-24.92 on). Looks to me like the nature of RISKS of IT projects can vary a lot depending on who is the final customer and who is paying the bill. ------------------------------ Date: Sun, 24 May 2009 01:30:16 GMT From: "Gene S. Berkowitz" <first.last_at_private> Subject: Re: FAA ATC shutdown (Gorman, RISKS-25.66) "The cheapest and most effective remedy for induced anxiety is to ignore those who profit from it. Easily spotted, they are the ones who continue to repeat what has been soundly discredited in the course of the public debate, and those who continue to grossly misrepresent the true state of affairs." Linda Gorman, Independence Institute, Golden, CO, Extremists Create Stress for Gain, 21 Mar 2000. http://www.i2i.org/main/article.php?article_id=294 Methinks Ms. Gorman should heed her own advice. ------------------------------ Date: Sat, 23 May 2009 20:50:25 -0500 From: "Al MacIntyre" <macwheel99_at_private> Subject: Re: FAA ATC shutdown (Cohen, RISKS-25.68) Subject: Is "security through obscurity" being called for in RISKS? > It is important for government to be open to the people in identifying > problems, but some stuff needs to be kept confidential from potential > trouble makers. The IG report included a road map to what security has been installed, what has not been installed, what vulnerabilities exist, at which FAA sites, and what any troublemakers can do right now. If the FAA ever gets caught up implementing standard security advice and patches, the security will be pretty darn good, but based on past track records, that may be a fantasy. The purpose of the inspection was to identify what needed to be fixed, but we know darn well that with government inspections that it can be years between problems identified, and them actually getting fixed. Before the report, I am sure many troublemakers already knew this stuff. After the report, an army of me-toos also know. The effect, of the IG report, included magnifying the risk the FAA has put itself into. It would be like you having a combination lock to your front door, and that combination being blasted on the Internet. Previously, the only people who knew the combination, were you, your family, some friends, some of their friends, some frequent vendors, and whoever has the hidden camera pointed at the touch pad where the secret pin code is keyed in. In your case, changing the password is fast & easy. The FAA does not have the funds, or expertise, to fix their almost total lack of cyber security. We are going to lose some aircraft full of passengers before this gets fixed. Thanks to the IG report, this will happen sooner rather than later. I think that all *we* the people need to know is that hackers can take over 99% of the Air Traffic Control in America, take down 75% of the public utilities, whatever the figures are, without spelling out step by step how to do it, for the next home grown idiot terrorists who right now can be caught by FBI confidential informant witnesses, but with this kind of report, don't need to use communications tapped by NSA to implement a plot. ------------------------------ Date: Sat, 23 May 2009 20:26:55 -0700 From: Fred Cohen <fc_at_private> Subject: Re: FAA ATC shutdown (MacIntyre, RISKS-25.69) I think that security through obscurity is a key component of the overall security plan of any real enterprise. I just get a bit annoyed when people act like it's somehow inappropriate to have/use it. Operations Security is all about deciding when and how to use obscurity, and deception is a part and parcel of any really good overall protection program I have seen. Fred Cohen & Associates 572 Leona Drive Livermore, CA 94550 http://all.net/ 1-925-454-0171 ------------------------------ Date: Sun, 24 May 2009 12:06:02 +0200 From: PK <djc_at_private> Subject: Re: On Government IT competence (Miller, RISKS-25.68) Scott Miller's note is a partisan rant which, arguably, belongs in part in RISKS as commentary on what belongs in RISKS. Its partisanship lies where it departs from fact, and from informed technical opinion, to express unsupported political opinion about the motivation of US political parties. (I use "partisan" here not in the narrow context of a particular two American political parties, but in its wide sense.) Here's a factual question related to RISKS in computing, one I touched in light of my own experience: is government -- not just US government -- worse at computing than private industry? (Not in my experience.) I'd welcome seeing some good data, though it's hard to imagine what it would be in light of the complexity of how large organizations actually operate, and of the large differences among businesses, and agencies of government, and governments, and fields of endeavor. > Further, how is the opinion expressed in Ms. Gorman's post less > appropriate to this list than the many others that I have read here on > various topics suggesting that government is uniquely competent? Unsupported opinion that government is uniquely [in]competent at technical work is as worthless as any unsupported opinion, and isn't a risk of computing. Let's go elsewhere for our unsupported opinion. I'd prefer it to be omitted from discussion here, or perhaps presented only as speculation when accompanied by facts that relate to risks of computing. Miss Gorman's examples also fail the sniff test, in a partisan way. > Electronic voting systems are IT projects largely contracted by > government exclusively to favored private (some would write > "mercantilist") contractors (Diebold, Sequoia, etc.) What does "contracted" mean here? I take it as a weasel word. Are current commercial electronic voting products designed and developed under contract to governments with accountability to the contractor? Or are they simply commercial products developed and sold, in the usual way, to meet a perceived market among public officials ignorant or desperate enough to be induced to buy them? In this venue I believe we know how badly most electronic voting products fail important criteria that representative governments should attend to for voting. We -- the world, not just the USA -- are only now undertaking serious discussion of what we need for non-paper balloting to be useful and trustworthy. My final point was, of course, to say that we needn't go far to find atrociously bad software, some of it in very wide use, that was inarguably developed entirely by private industry. ------------------------------ Date: Sat, 23 May 2009 23:49:55 -0400 From: Monty Solomon <monty_at_private> Subject: eCrime Researchers Summit CFP The fourth annual APWG eCrime Researchers Summit will be hosted in Oct 2009, in Tacoma, WA. Original papers on all aspects of electronic crime are solicited for submission to eCrime '09. Topics of relevance include but are not limited to: * Phishing, rogue-AV, pharming, click-fraud, crimeware, extortion and emerging attacks. * Technical, legal, political, social and psychological aspects of fraud and fraud prevention. * Malware, botnets, ecriminal/phishing gangs and collaboration, or money laundering. * Techniques to assess the risks and yields of attacks and the success rates of countermeasures. * Delivery techniques, including spam, voice mail and rank manipulation; and countermeasures. * Spoofing of different types, and applications to fraud. * Techniques to avoid detection, tracking and takedown; and ways to block such techniques. * Honeypot design, data mining, and forensic aspects of fraud prevention. * Design and evaluation of user interfaces in the context of fraud and network security. * Best practices related to digital forensics tools and techniques, investigative procedures, and evidence acquisition, handling and preservation. http://www.ecrimeresearch.org/2009/cfp.html ------------------------------ Date: Thu, 29 May 2008 07:53:46 -0900 From: RISKS-request_at_private Subject: Abridged info on RISKS (comp.risks) The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. The mailman Web interface can be used directly to subscribe and unsubscribe: http://lists.csl.sri.com/mailman/listinfo/risks Alternatively, to subscribe or unsubscribe via e-mail to mailman your FROM: address, send a message to risks-request_at_private containing only the one-word text subscribe or unsubscribe. You may also specify a different receiving address: subscribe address= ... . You may short-circuit that process by sending directly to either risks-subscribe_at_private or risks-unsubscribe_at_private depending on which action is to be taken. Subscription and unsubscription requests require that you reply to a confirmation message sent to the subscribing mail address. Instructions are included in the confirmation message. Each issue of RISKS that you receive contains information on how to post, unsubscribe, etc. => The complete INFO file (submissions, default disclaimers, archive sites, copyright policy, etc.) is online. <http://www.CSL.sri.com/risksinfo.html> The full info file may appear now and then in RISKS issues. *** Contributors are assumed to have read the full info file for guidelines. => .UK users should contact <Lindsay.Marshall_at_private>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line. *** NOTE: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks for current volume or ftp://ftp.sri.com/VL/risks for previous VoLume <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue. Lindsay has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r <http://the.wiretapped.net/security/info/textfiles/risks-digest/> . ==> PGN's comprehensive historical Illustrative Risks summary of one liners: <http://www.csl.sri.com/illustrative.html> for browsing, <http://www.csl.sri.com/illustrative.pdf> or .ps for printing ==> Special Offer to Join ACM for readers of the ACM RISKS Forum: <http://www.acm.org/joinacm1> ------------------------------ End of RISKS-FORUM Digest 25.69 ************************Received on Sun May 24 2009 - 19:15:47 PDT
This archive was generated by hypermail 2.2.0 : Sun May 24 2009 - 19:40:31 PDT