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…
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.]
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/
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
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.
> [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]
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.
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.
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]
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 ;-)
"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
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.
> 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.
"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.
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.
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
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.
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
Please report problems with the web pages to the maintainer