[Recall that RISKS has always sought to include success stories on approaches that can avoid the types of risks that continually reappear here. Here is one example of something that might be educationally worth considering. PGN] [From Dave Farber's IP group. PGN] Archives: https://www.listbox.com/member/archive/247/=now Joab Jackson, Tokeneer case study serves as an example of writing low-defect, highly-reliable code, researchers claim, *Government Computer News* weekly newsletter. The National Security Agency has released a case study showing how to cost-effectively develop code with zero defects. If adopted widely, the practices advocated in the case study could help make commercial software programs more reliable and less vulnerable to attack, the researchers of the project conclude. The case study is the write-up of an NSA-funded project carried out by the U.K.-based Praxis High Integrity Systems and Spre Inc. NSA commissioned the project, which involved writing code for an access control system, to demonstrate high-assurance software engineering. With NSA's approval, Praxis has posted the project materials, such as requirements, security target, specifications, designs and proofs. The code itself, called Tokeneer, has also been made freely available. ``The Tokeneer project is a milestone in the transfer of program verification technology into industrial application," said Sir Tony Hoare, noted Microsoft Research computer scientist, in a statement. "Publication of the full documents for the project has provided unprecedented experimental material for yet further development of the technology by pure academic research.'' Developing code with very few defects has long been viewed as a difficult and expensive task, according to a 2006 paper by Praxis engineers describing the work that was published in the International Symposium on Signals, Systems and Electronics. For this project, three Praxis engineers wrote 10,000 lines of code in 260 person-days, or about 38 lines of code per day. After the project was finished, a subsequent survey of the code found zero defects. Moreover, Tokeneer meets or exceeds the Common Criteria Evaluation Assurance Level (EAL) 5, researchers said. Common Criteria is an ISO-recognized set of software security requirements established by government agencies and private companies. Industry observers have long concluded that it would be too expensive for commercial software companies to write software programs that would meet EAL 5 standards. According to the 2006 paper, the engineering team used a number of different techniques for writing the code, all bundled into a methodology they call Correctness by Construction, which emphasizes precise documentation, incremental developmental phases, frequent verification and use of a semantically unambiguous language. The developers wrote the code in a subset of the Ada programming language called SPARK, which allows for annotations that permit static analysis of the program. They used the GNAT Pro integrated developer environment software from AdaCore. "This case study has shown that software-based security products can be built that are reliable, verifiable and cost effective against Common Criteria guidelines," the paper concluded. "The bar has been raised for both procurers and suppliers."
A reformatting error in an Excel spreadsheet has cropped up in the largest bankruptcy case in U.S. history, prompting a legal motion by Barclays Capital Inc. to amend its deal to buy some of the assets of Lehman Brothers Holdings Inc. The law firm representing Barclays filed the motion (download PDF) on Friday in U.S. Bankruptcy Court for the Southern District of New York, seeking to exclude 179 Lehman contracts that it said were mistakenly included in the asset purchase agreement. The firm — Cleary Gottlieb Steen & Hamilton LLP — said in the motion that one of its first-year law associates had unknowingly added the contracts when reformatting a spreadsheet in Excel. [Source: Excel error leaves Barclays with more Lehman assets than it bargained for, *Computerworld*, Oct 14 2008] http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9117143 [Another Excel-lent risk report, also noted by Chris Leeson, who observed that there should be fireworks at the hearing scheduled for 5 Nov, which will be just in time for Guy Fawkes Night! PGN]
Police have arrested innocent people due to faulty fingerprint analysis but have not determined how many cases were affected by such errors. The *Los Angeles Times* has obtained an internal police report that notes two cases in which charges were dropped after problems with the fingerprint analysis were discovered, blamed on "shoddy work and poor oversight". One fingerprint analyst, who was involved in both the mishandled cases, was fired and three others were suspended and two supervisors replaced. "This is something of extraordinary concern," said Michael Judge, public defender for Los Angeles County. "Juries tend to afford the highest level of confidence to fingerprint evidence. This is the type of thing that easily could lead to innocent people being convicted." [Source: AP item, 17 Oct 2008; PGN-ed, thanks to Lauren Weinstein] http://www.dailynews.com/breakingnews/ci_10743941
*The Washington Post*, 7 Oct 2008 http://www.washingtonpost.com/wp-dyn/content/article/2008/10/07/AR2008100703245.html "[Some of the involved officials] said the activists' names were entered into the state police database as terrorists partly because the software offered limited options for classifying entries." (from the second page). The gist of it is that the MD police added names of people who were nonviolent protesters to a terrorist watch list/database; their names were also included on a federal database as well. While there may be software design and use issues involved (such as: did the database admins have an incomplete grasp of all the "use cases" to be tracked? Were the choices deliberately limited for some political or statistical purpose?) the most potent risk may be that "computer problems" can be used as an excuse for a much more serious human error.
From http://www.theregister.co.uk/2008/10/14/tsa_screener_theft/: A baggage screener for the US Transportation Security Administration has confessed to brazenly stealing a trove of electronics gear from the luggage of passengers he was sworn to protect, federal prosecutors said. Pythias Brown, 48, of Maplewood, New Jersey, regularly sold the high-priced video cameras, laptop computers, and global positioning systems on eBay using the handle "alirla," according to a criminal complaint filed in federal court in Newark. Brown told investigators he began stealing the items in September 2007 while screening luggage at Newark Liberty International Airport.
This is a biggie: http://www.theregister.co.uk/2008/10/10/organized_crime_doctors_chip_and_pin_machines/ In a nutshell, criminals installed mobile phone kit INSIDE credit card readers before they arrived at merchants and shops, thus sending details of every card used on those terminals to criminals in Pakistan. Not sure how this was discovered, but the scale is breathtaking. [Followup: I requested more details, and Peter replied. PGN] You should watch a BBC program, available on YouTube. In part 2, my favourite news reported, Jeremy Paxman, goes into grilling mode, and he tears strips off the credit card suppliers who are trying to pretend it's not a big deal. Well, it is. See http://www.youtube.com/watch?v=L7QzOcZAwbg, part 2 is http://youtube.com/watch?v=pHdX3ZYEvXw. It's quality TV. (Paxman can be incredibly obnoxious if he doesn't get a straight answer, enjoy.) Also features Ross Anderson from Cambridge, oh, and they managed to get a terrorist angle on it (grin). OK, below an elaboration. I have omitted by part 2 that I'm one of the two principal authors of an algorithm that addresses that mutual authentication problem in full (which will become part of our token firmware Q1 2009 or maybe earlier), I didn't really want to blow my own horn (or be seen to), nor do i want to play the marketing buffoon. I solve problems, not flog gadgets - and I will get back to you with something new there too. FYI, www.axsionics.ch, happy to send you docs. Interesting challenge to discover.. 1 - it's an add-on, so the electronics won't detect changes as inputs are tapped before they get to the tamperproofing. 2 - if you block mobile comms there will be another way. You're fixing the wrong problem (more on that later). The good news is that the method they used caused interference, eventually leading to discovery. It sort of radiated trouble.. A disclosure before I start: I actually work for the company that solved this whole problem about a year ago (well, actually several years ago, but the startup has grown into a "real" company :-). Who wants to know will find out easily enough, but my reply is not for marketing. Transaction challenges (also by banks): 1 - ensure that, as a payment provider, you're talking to the actual account holder 2 - assure to the account holder that you are, indeed, the payment handler 3 - secure this whole process to ensure authentication, authorisation, confidentiality and integrity of the process (bonus challenge: 4 - ensure that a transaction is actually as expected by the client and get an approval that supports non-repudiation) Point 1 is done by PIN. The above hack destroys that assurance, but it was IMHO weak to start with, even though most of my cards have 6 digits. The ones with signatures have my face next to the signature (given the quality of the picture mainly to frighten people). How do I know as provider that "owner" and card are together when this happens? I don't - at a point of sale Chip & PIN has driven the assumption that "it must be so", and merchants no longer have any means to check other than picture cards which nobody examines other than with a signature. Point 2 is where both ATMs and credit card terminals fall down, as well as banks that call their customers - how do you know it's really the bank? How do I know I'm entering my PIN safely? Nothing assures the user of the rightful recipient of their always-the-same PIN.. Point 3 is inadequately dealt with by the "secure shell" approach a("secure" network and "secure" terminal, which means a rogue insider -network or hardware- nulls your whole approach). It is moderately OK from a risk management point of view as you contain the fraud ability to a limited audience, but as soon as someone gets *really* creative many will follow the new path - QED above. With Internet banking there is a dependency on the user terminal being moderately safe, something you can never ensure as a bank. In addition, OTP lacks feedback, challenge - response devices work with cleartext so a Man In The Middle or Man In The Browser remains possible. Note that we started this discussion with a credit card which has NOTHING apart from a secure terminal - if it isn't you thus have a major problem. Point 4 is now dealt with with out-of-band methods - get a display and confirmation via another route, typically mTAN. But do you really want transaction details travel via an insecure network which principally has no SLA for SMS? SMS traffic is the first that gets dropped if the cell gets busy.. In credit cards PIN entry is assumed to function both as authentication and authorisation, but the above hack would have worked even if those steps were with different PINs. There are a few solutions to the whole picture, but keep in mind that the base assumption should always be that the system the card is used on is infected/hacked/tampered with, which rather reduces the number of options. In addition, improving security has normally a tendency to make life harder for the poor end user who has to go through more ritual, incantations and incense burning on behalf of the relevant issuer to keep things safe.
Mark Smith's message reminds me of a book I just received: Richard Hayes Phillips Witness to a Crime: A Citizen's Audit of an American Election Canterbury Press, Rome NY, March 2008 ISBN 978-0-9798722-3-5 This is an extraordinarily detailed analysis of the 2004 presidential election in Ohio, and perhaps a harbinger of things to come. PGN]
This needs to proceed very, very carefully: > The Progressive Conservative government plans to start slowly, at first > offering only a bit of information such as vaccination records. However, > the end goal is to post everything, including prescriptions, X-rays and > laboratory test results. [...] > > Mr. Brisson said addressing security and privacy concerns will be > paramount as the province builds the new e-health service. He's hopeful > that 'an incremental approach' will not only build up confidence but also > usage. > > He said Alberta is in a position to take this step because it's already > developed an electronic medical record system accessible exclusively to > health-care providers. Every other province and territory is now setting > up similar paperless systems. http://tinyurl.com/6755ak http://www.theglobeandmail.com/servlet/story/RTGAM.20081017.health17/BNStory/National/home The whole "exclusively to health-care providers" bit sounds a bit naive, given the reports out of the US of hospital and IRS employees accessing records of celebrities. Maher Arar is probably glad that the Syrians couldn't get his medical records: http://en.wikipedia.org/wiki/Maher_Arar Can government agencies request (warrant or not) a copy of your medical records if it's in a central database? We generally know how to secure paper records, I don't think we've quite figured out how to do the same with electronic records.
Ben Worthen, New Data Privacy Laws Set For Firms, *The Wall Street Journal*, 16 Oct 2008 Alicia Granstedt, a Las Vegas-based hair stylist who works for private clients and on movie sets, never worried about conducting most of her business through e-mail. Ms. Granstedt regularly receives e-mails from customers containing payment details, such as credit-card numbers and bank-account transfers. Since she travels frequently, she often stores the e-mails on her iPhone. But a Nevada law that took effect this month requires all businesses there to encrypt personally-identifiable customer data, including names and credit-card numbers, that are transmitted electronically. After hearing about the new law, Ms. Granstedt started using e-mail encryption software, which requires her clients to enter a password to read her messages and send responses. It is a hassle, "but I can't afford to be responsible for someone having their identity stolen," she said. Nevada is the first of several states adopting new laws that will force businesses — from hair stylists to hospitals — to revamp the way they protect customer data. Starting in January, Massachusetts will require businesses that collect information about that state's residents to encrypt sensitive data stored on laptop computers and other portable devices. Michigan and Washington state are considering similar regulations. ... http://online.wsj.com/article/SB122411532152538495.html
Devices and Comprehensive Data Security Programs Miriam Wugmeister and Charles H. Kennedy, Morrison & Foerster, Sep 2008 http://www.mofo.com/news/updates/bulletins/14495.html Randy Gainer, New State Laws Require Extensive Data Security Plans and Encryption, Davis Wright Tremaine LLP, Sep 2008 http://www.dwt.com/practc/privacy/bulletins/09-08_DataSecurityPlans.htm 201 CMR 17.00: Standards for The Protection of Personal Information of Residents of the Commonwealth http://www.mass.gov/?pageID=ocaterminal&L=4&L0=Home&L1=Consumer&L2=Privacy&L3=Identity+Theft&sid=Eoca&b=terminalcontent&f=reg201cmr17&csid=Eoca Ben Worthen, New Data Privacy Laws Set For Firms, *The Wall Street Journal*, 16 Oct 2008 http://online.wsj.com/article/SB122411532152538495.html
Regarding the issue about Amazon allowing >1 login per e-mail address, its a historical legacy that they probably hate. Remember back in 1995 when the whole family had one compuserve or AOL e-mail address? That's when Amazon was created, and that is where they came up with the fact that an Amazon user does not have a 1:1 mapping of e-mail->userID. What they do have is a mapping of (e-mail,password)->userID; you can create two accounts with the same e-mail address, but you will get into trouble if you try and give them the same password. I'm not sure what happens, so try it and see. The newer Amazon services, such as the Amazon Web Services, have a stricter "one e-mail address" per account rule. Clearly their support organisation has learned the error of the original design decision.
My wife recently bought a new car and the dealer arranged financing through a local credit union. This credit union has a web site that allows one to check on their accounts and do transfers between accounts and such. I wanted to use the site to make sure the first payment was credited correctly so I attempted to log in. First off, the owner of the account has to call them so they can send out a password to be used for the initial log in so we did that. When I received the password, I again went to the web site and it required me to change the default password. So far, so good. It then required me to set up some security questions by choosing from a fixed list of perhaps ten questions. One of the first was "What was the color of your first car?" I picked that one since I thought that was easy for me to remember but difficult for anyone else to know or find out so I typed in the answer - "red". I was told that I had to enter at least four characters for the answer to the question. I really had no idea what to do except laugh at the programmer who came up with this one. Figuring that this was the case for all of them, I tried again ... "What is your father's middle name?" "Bud" "You must enter at least four characters for the answer to this question." Obviously we must distort reality to pass this test.
I wanted to transfer some money between two of my IRAs (banks unnamed). I logged into the one where the money was to go (I prefer pull to push). I anticipated having to go to the source, print out a form, signing it, and mailing it in. Instead, all I had to do was, at the receiving site, enter the source account number, and request a transfer. No authentication of any type was asked for. Less than a week later, the money was transferred. I don't know if this is common, but this worries me. Can anyone withdraw money from my account just by knowing the account number? I did not see any matching of names between the accounts.
Stallman cautions against the "cloud computing" myth: http://lists.gnu.org/archive/html/bug-findutils/2008-10/threads.html http://techblog.dallasnews.com/archives/2008/10/cloud-computing-is-stupidity-s.html http://blogs.zdnet.com/carroll/?p=1880 http://www.guardian.co.uk/technology/2008/sep/29/cloud.computing.richard.stallman http://blogs.computerworld.com/rms_hates_cloud_computing_says_you_should_too and also http://www.osnews.com/thread?332053 if you have the right browser. I just want to add a warning that one day when one's Gmail breaks, one will attempt for the first time in one's life to contact the massive Google Corporation. Whereupon one will discover that despite their best intentions, due to their massive scale, there is little chance one will get a personal reply. "No problem" you might say, "there will certainly be many others in the same boat, so it will get fixed". Well, yes that's usually how it works with power outages and the electric company, if not at least you can still always just call their local service center. [When Gmail breaks? What about the complaints that repeated failed login attempts (a simple type of denial-of-service attack) results in YOUR Gmail account being disabled, with no easy way to get it reactivated? PGN]
PGN mentions "outliers" (RISKS-25.37) — leading me to muse on the automatic elimination of aberrant points. In some sporting events, a common practice is to eliminate the highest and lowest judges' scores, and to average the rest. But now consider generalizing on the idea: It may not be generally known, for example, that there are configurations of equally-weighted points in 3-D space for which the pair of points that are farthest apart from each other are the two points that are closest to the center of gravity of the lot! [I guess that very few RISKS readers will identify Ken with one of his most delicious innovations (if I remember correctly from our Bell Labs days in the 1960s): the 17-sided unistable uniform solid that will always roll over onto the same side: the ultimately loaded-but-unloaded die. Very dicey matter. PGN]
A recent article (RISKS-25.37) mentioned the danger that the "something you know" used to authenticate an account may sometimes be "something everybody knows". This brings to mind a newspaper article I once read on computer security. While for the most part it was a pretty decent article, I winced when the reporter mentioned that his own e-mail account had once been broken into, even though he'd carefully chosen the extremely obscure password "THX1138". While that looks pretty much like a random string of letters, it is in fact the name of George Lucas's first film, from his student days. I don't know what the overlap is between hackers and science fiction fans, but I'm sure it's substantial. "THX1138" is probably more secure than "Gandalf", but it's still nothing to feel safe with. The moral: choose a *really* secure password. I suggest "Picard" or "Skywalker".
This is one integer-overflow problem where it seems an opportunity was lost by not using a signed integer... Oh, well, the timing is fortuitous: just when this counter needs another digit, one has become available from the Dow Jones Industrial Average.
I tried to read the story from the "Athens News" but every single link takes me into a popup add zone for domains. I presume the "Athens News" website has something hacked into it because I see the story briefly but then I'm thrown elsewhere.
Please report problems with the web pages to the maintainer