security gaffe The Chancellor was rocked by a new crisis this evening over the loss of confidential bank details of virtually every family in Britain. Alistair Darling had to make an emergency statement to the Commons revealing that records of 7.2 million bank accounts of all parents or guardians who claim child benefits had gone missing. MPs gasped when he revealed that the names, addresses, bank numbers and National Insurance numbers of all those affected had been on two computer discs which had been lost. A total of 25 million people's names are on the discs, potentially leaving them all at risk of identity fraud. Britain's most senior taxman, Paul Gray, quit his 170,000-pound--a-year job as head of HM Customs and Revenue in the wake of the Treasury blunder. <http://tinyurl.com/2ubzzm>, full URL <http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=495188&in_page_id=1770&in_page_id=1770> At present it appears the information was at least encrypted, but it defies belief that data of such sensitive nature was despatched in this form without being accompanied with the most basic form of tracking. Plus ca change.
According to more recent reports, the extreme blunder made by the UK "HM Revenue and Customes" by sending two CDs with the personal details of approx 25 million people per unsecured courier is worse than first reported. Later news reports suggest that the original story of this data being at least "encrypted" may be inaccurate, or may be a bit of an overstatement when it comes to the kind of encryption used (ROT 13, maybe?). http://uk.news.yahoo.com/pressass/20071121/tuk-astonishment-over-information-error-6323e80_1.html This is an absolutely unbelievable blunder, especially given the sensitivity of the data. In addition, there are electronic connections on multiple security levels between those departments - there was really no need at all for that data to travel physically. And this lot wants the population to agree to a central IDcard scheme?
Two CD-ROMs containing the entire Child Benefit database held by Her Majesty's Revenue and Customs (HMRC) have gone missing in transit from the HMRC Child Benefit Office in Washington, Tyne and Wear, to the National Audit Office (NAO) in London. The information here is mostly a summary of pages of the BBC's site: http://news.bbc.co.uk/1/hi/uk_politics/7103566.stm http://news.bbc.co.uk/1/hi/uk_politics/7106366.stm http://news.bbc.co.uk/1/hi/uk_politics/7104368.stm ... updated from BBC Radio bulletins of 21st and 22nd November. Information from commentators to The Register is also interesting: http://www.theregister.co.uk/2007/11/21/reader_comments_on_hmrc/page2.html The New York Times covered the story on 22nd November: http://www.nytimes.com/2007/11/22/world/europe/22data.html?th&emc=th For non-UK readers, the Child Benefit is a fixed payment to parents, (normally the mother) of every child in the UK under 16, and to older children in full-time education. It is taken up by almost 100% of those eligible. Amounts: 18.10 pounds a week for the first child; 12.10 pounds a week for further children. ($36.30 for the first child; $25 per additional child - NYT) Payments are administered by HMRC. The NAO is the UK watchdog body on public expenditure, and needed to know the amounts paid in Child Benefit, as part of its normal work. The following was the sequence of events (adapted from the BBC report): MARCH 2007 The head of NAO requested from the manager of Child Benefit a copy of the Child Benefit records for the whole of the UK. Only financial information was needed. The request made it clear that personal details could be removed, to "de-sensitize" the data. The manager of Child Benefit e-mailed the head of NAO to say that de-sensitizing the data could not be done for reasons of cost, and that the complete data would be sent. This message was copied to one of the directors of HMRC. A "junior official" at HM Revenue and Customs sent to the NAO a full copy of HMRC's child benefit data. That information was later safely returned. 18 OCTOBER Child benefit data was again sent to the NAO by a "junior official", using the courier company TNT, which operates the HMRC's internal mail system. The package contained two CDs, containing details of 25 million individuals. It has been reported that the data was password protected but not encrypted. The package was not recorded or registered, and failed to arrive. (The repeated statements that the package was "not recorded or registered" are puzzling. See my comment below.) 24 OCTOBER The NAO told HMRC it had not received the package. An HMRC spokeswoman said the official believed it may have been delayed by the postal strikes or in the NAO's office move and did not report it. A second copy was sent by registered post and arrived safely. 8 NOVEMBER Senior HMRC management were informed that the 18 October package was missing. 10 NOVEMBER The Chancellor, Alistair Darling, was informed and told Prime Minister Gordon Brown. Mr Darling ordered an immediate investigation and searches of all premises where the package might be, as well as action to ensure it does not happen again. 12 NOVEMBER Mr Darling was told by HMRC that evidence has been found which might help to find the missing package (as stated on the BBC web site: there has been no public statement about what this "evidence" might have been). 14 NOVEMBER The chancellor decided the HMRC searches had failed and told HMRC chairman Paul Gray to call in the Metropolitan Police. 15 NOVEMBER The chancellor went to Information Commissioner Richard Thomas, who agreed that remedial action must be taken before a public statement is made. (Keeping Joe Public and his missus informed is the lowest priority, as usual!) 12-18 NOVEMBER Mr Gray told Mr Darling he felt he should resign (i.e., Mr Gray, not the Chancellor!). The Chancellor sought the advice of the Financial Services Authority and Serious Organised Crime Agency, while banks were alerted by HMRC. 20 NOVEMBER Mr Gray resigned following an announcement that Mr Darling was to make a statement to the House of Commons. The chancellor outlined what had happened and announced an investigation of HMRC's security procedures by PricewaterhouseCoopers chairman Kieran Poynter, alongside the Independent Police Complaints Commission, which monitors the HMRC. - - - - Some interesting points arise from this comedy of errors: We have been continually told that the posting of the CDs was done by a "junior official" who was acting "in breach of security procedures", and a 23-year-old civil servant has duly resigned. It was speculated that he might have been a temporary, but it has now come to light that he was a permanent member of staff. As such, he should have known the "security procedures", whatever these were. Also, as a civil servant, he would have been subject to the Official Secrets Act. Several serving or retired civil servants have made interesting comments to The Register (see URL above) about this "junior" official. For security reasons, a junior would not have had a CD burner as part of his office workstation. The active co-operation, as well as authorisation, of his manager would therefore have been required. Also for security reasons, he would not have had a personal e-mail address at the office. There is, in any case, a 4Mb size limit to e-mail attachments, which would preclude electronic transmission (encrypted or otherwise) and was presumably the reason for sending CDs by snail-mail. One informed guess is that what was sent was a .mdb file, zipped using a password. The junior official was therefore following his manager's explicit instructions, and using a procedure which had become routine. His responsibility should have ended at the point when he dropped the package into the internal mail, but he became a convenient scape-goat when the procedure failed, as it would sooner or later. However, that was before the existence and contents of the e-mail from the head of Child Benefit Office to the head of NAO were made public on the 21st November. (It seems that it was leaked to the Conservative Party, who were not slow to use it as a rod with which to beat the government.) The fact that it was cc'd to a director of HMRC means that the top brass were fully aware that unencrypted personal data for half the people in the UK were routinely being shipped on CD by an insecure route. The contention that de-sensitizing the data would have been too expensive does not bear scrutiny. If all that was needed was to delete names, addresses and NI numbers, then this amounts to deleting some columns from a relational database. which is a few minutes' work. However, it is likely that the NI number would be at least a part of the primary key, so that it could not be removed without compromising the integrity of the data. It would have been necessary to have replaced it with another unique but arbitrary identifier. Also, the NAO might have required at least the first part of the post code in order to break down payments by region. All of this is pure speculation, of course. Regarding the peculiar statement that the package was "not recorded or registered": "Recorded delivery" and "Registered mail" are special services provided by the UK Post Office, and mean that, for a charge, one can ensure that a valuable package obtains VIP treatment or that its movements can be fully traced, which is not the case with normal postal delivery. I use it if, for example, I need to send my birth certificate somewhere for an official purpose. One would expect a courier to "record and register" every item entrusted to its care. (If I buy a pair of socks over the internet, I have to sign for it when the man in the van turns up on my doorstep.) TNT would (surely?) have signed in and out *every* package that they shipped, and must have been able to demonstrate basic competence in doing this in order to get the contract for handling HMRC's internal mail. Regarding the possibilities of fraud: The data includes: National insurance (NI) number Name, address and birth date Partner's details Names, sex and age of children Bank/savings account details ... quite useful for an identity fraudster, particularly the NI number. There is plenty of scope here for a fraudster to redirect payments. We have been told by the Chancellor and Prime Minister that there is no evidence that the data has fallen into the "wrong hands", but since no-one knows whose hands it is in (if anyone's: it might be lying in the back of a van) this is just the usual reassuring bull***t from the government. In two separate incidents in September, records of about 15,000 people's details went missing after being sent by HMRC to Standard Life Insurance, and a laptop containing around 400 ISA (individual savings accounts) customers' details was stolen. (HMRC deals with tax as well as benefits.) Government data security is now a *very* hot political potato. Paul Gray has at least had the decency to resign. Whether his head will placate the mob remains to be seen. In the meantime, the allegations that the government could not guarantee adequate security for the data to be held for the proposed national Identity Card scheme have gained new force. Peter Mellor; Mobile: 07914 045072; email: MellorPeter@aol.com Telephone and Fax: +44 (0)20 8459 7669
I've just come across the document Bad Health Informatics Can Kill from the Working Group for Assessment of Health Information Systems of the European Federation for Medical Informatics (EFMI) "ICT can have positive impact on health care, but there are also examples on negative impact of ICT on efficiency and even outcome quality of patient care. Medical informaticians should feel responsible for the effects of ICT on patients and public. Systematic analysis of ICT errors and failures is the precondition to be able to learn from negative examples and to design better health information systems. This document contains summaries of a number of reported incidents in healthcare where ICT was the cause or a significant factor. For each incident or problem at least one link to a source will be provided. With the following list, we want to raise awareness on this important issue, and provide information for further reading" Full document at: http://iig.umit.at/efmi/badinformatics.htm School of Computing Science, Newcastle University, Newcastle upon Tyne, NE1 7RU, UK +44 191 222 7923 http://www.cs.ncl.ac.uk/~brian.randell/
NASA has been flying the Space Shuttle for more than a quarter century without ever having a mission in space over New Year's Eve, because its computer software could not be trusted to behave correctly when the Julian date rolled over from 365 or 366 to zero. Earlier this year, NASA announced that it had finally fixed the Year End Rollover (YERO) problem (<http://www.nasaspaceflight.com/content/?cid=5026>). When they scrubbed today's STS-122 Atlantis launch attempt because of problems with the engine cut-off fuel sensors, NASA set the next try for no earlier than January 2, 2008, in part (reportedly) because of YERO software concerns. It appears that NASA doesn't have a great deal of confidence in their date problem fix. Does anyone have details of where this issue stands now?
On 30 Nov 2007 an Amtrak passenger train approaching Chicago's Union Station slammed into the rear of a freight train occupying the same track. Speed recorders showed that the train was doing 40mph when the engineer went into emergency about 9 seconds before the crash. The signal on the line, operated by Norfolk Southern, was set so that the train should have been going 15mph, prepared to stop. According to an article in the 4 Dec 2007 edition of the *Chicago Tribune* http://www.chicagotribune.com/news/local/chi-traincrash_04dec04,0,6705498.story a cause of the accident may have been a combination of the engineer's relative inexperience and the surprising (to me) fact that the same signal indication on different railroads may mean different things. According to the Tribune: "The system of color-coded signals evolved over the last century or more, and the operating rules that govern them were created independently, based on the need of individual railroads." The NS signal was showing red-over-yellow which, on that railroad signifies the 15mph restriction. The Amtrak train in question began it's journey from Grand Rapids, MI to Chicago on a different railroad where the red-over-yellow indication can mean something else. Also from the article: "An engineer's job these days is a lot more difficult than people realize," said Chip Pew, a safety specialist in the rail division of the Illinois Commerce Commission. "Envision something as simple as a stop sign to mean as many as four different things depending on what railroad territory and what state you are in," Pew said. "We need to consider at least some national operating rules so red over yellow means red over yellow everywhere to eliminate the possibility of misinterpretation." Not from the article: according to a friend who is knowledgeable about railroad signaling systems says that red-over-yellow always means some form of "slow down stupid" even if not exactly the same form on each railroad.
Recent developments in DUI litigation unexpectedly bleed into the realm of computer security. INTRODUCTION Computer security enthusiasts are naturally interested in software quality. They know that proper software engineering and development is necessary for the justified extension of trust to computing and communication systems. The search for trust appears to have lately received an unexpected ally: according to a small but growing number of DUI defendants, breath alcohol testing devices cannot be trusted unless defense experts are permitted to analyze the source code for the software that controls them. Is there now an alliance between DUI defendants and computer security professionals? To the extent that they are both interested in trust of computing services, the answer is, "yes." The search for trust is really a search for dependability. Dependability is an umbrella concept in computer science that includes five core components: integrity, availability, safety, maintainability and reliability.1 Those who pursue computer security recognize the first two components as essential. Those who use evidence that is i) scientific or technical, and ii) the output of a computer should recognize the last as critical.2 Thus, DUI defense and computer security are indeed joined by their respective pursuits of computer dependability and trust. However, this alliance is certainly not to the exclusion of police, crime labs, and prosecutors. To the extent evidence is the output of a computer, such as a breath test device, law enforcement pursues computer dependability with zeal equal to (probably exceeding) that of the defense. Law enforcement pursues the reliability of breath test evidence using a range of elaborate methods. Central to those methods is black box testing. In this context, black box testing involves the input of certified known solutions of ethanol into a breath testing instrument. The idea is that, if the instrument measures the known inputs correctly both before and after the defendant's tests, then by implication the instrument must be working properly and accurately at the time of the defendant's tests. At trial, prosecutors depend, in part, on this "before/after" testing to persuade judges and juries that evidence from a given breath testing instrument is reliable and trustworthy. Some DUI defendants are recently claiming that this black box testing is insufficient to establish the reliability of breath test evidence. One notable example is the case of State v. Chun, a consolidated case involving 20 defendants who collectively demanded that the State of New Jersey (hereinafter, "State") disclose the source code for its breath testing instrument, the Draeger brand Alcotest 7110 MKIII-C.3 The Chun defendants alleged that the reliability of the State's breath test evidence could only be established by a post-hoc source code review or audit. In particular, they claimed that "an actual source code review is necessary as there could be hidden techniques [in the software] that would allow for altering data and/or blatant coding errors that skew the accuracy of the instrument's results."4 If permitted, a post-hoc source code review would be quite a commitment, since the firmware for the Alcotest breath tester contained more than 45,000 lines of C/C++ code. After protracted litigation, the Chun defendants convinced a court to grant review of the Draeger Alcotest source code firmware, version NJ3.11 (the actual version at issue in New Jersey). So that the defense was not left with the first, last, and only word on the "quality" of the NJ3.11 firmware, Draeger also contracted an expert to conduct a source code review. Finally, to resolve anticipated differences and to facilitate understanding, the court appointed its own expert to report on the work of the parties' experts. THE CHUN SOURCE CODE REVIEWS The defense hired Base One Technologies to conduct a static source code review. Base One used the following tools to conduct its review: Lint, MS Visual C++ Development Environment and Compiler, Borland C++, IAR Embedded C Compiler, Understand C code analyzer, Source Format X, Beyond Compare, and others. Since at least some of the comments for the NJ3.11 source code were in German, Base One used AltaVista Babelfish web translation service to translate the comments into English.5 In its final report, Base One made a number of criticisms of the NJ3.11 firmware.6 Perhaps the most incendiary charge, and the one most quoted on DUI defense attorney blogs, was that, in some cases, if a diagnostic routine fails, then the Alcotest "will substitute arbitrary canned data values" thereby affecting the breath measurements. The apparent implication of this allegation is that the Alcotest (at least for version NJ3.11) fabricates breath test evidence. Base One made other notable findings. It said there was "proof of incomplete testing" of the code. This is an odd observation to make since it is well established that complete testing of non-trivial software is "impossible."7 Base One also wrote that "catastrophic error detection" was improperly disabled; that the firmware would not pass "U.S. industry standards" for software and testing; that the programming "does not insulate/protect modules or data"; and that "incorrectly coded or modified functions can inadvertently modify a data value not part of that routine's sphere of influence." Prior to submission to the Chun court, Base One's report was assessed by the court's source code expert, the CMX Group.8 CMX was mostly critical of Base One's report. In particular, CMX wrote that more than a few of Base One's claims were "unsupported," or contained "misleading observations," or were "pure speculation," or had no supporting evidence, or were flatly contradictory. CMX also impugned Base One's knowledge of software standards as being "inaccurate." Further, CMX said that Base One used inappropriate "innuendo" as well as unsubstantiated phrases such as "clearly" and "ample evidence," and also used non-specific phrases such as "industry standards" without sufficient elaboration. Finally, CMX found as empirically unsupported Base One's claim that the NJ3.11 firmware substitutes arbitrary data values for authentic ones. CMX also wrote that the Base One reviewer may be "unaware" of some system testing tools necessary to perform an adequate review, or may not have had much experience in the relevant technologies. CMX noted that Base One's unspecific, misdirected, or false statements demonstrated "why companies do not want to expose their internal code.[since] [i]t looks as if they are covering up error while, in reality, this is the way that all code has to be written for controlling and coordinating hardware." In sum, CMX concluded Base One "[did] not succeed" in dislodging the presumption of reliability of the Alcotest 7110 MKIII-C breath testing device, firmware version NJ3.11.9 For its part, Alcotest manufacturer Draeger hired SysTest Labs, a nationally known software testing company, to review of the NJ3.11 firmware. SysTest conducted a line-by-line, static code review, but did not stop there: it also performed code tracing, reverse engineering, code navigation and code metrics. SysTest used Understand C, Fortify SCA, and in-house software assessment tools. Instead of using Babelfish, SysTest employed a professional, human translation service to interpret the German source code comments. SysTest documented 602 hours of labor on its source code review. SysTest also found problems with the NJ3.11 code. It noted that critical test data was stored in global variables, a practice that is undesirable "because any function in the application can [theoretically] change the data." SysTest noted at least 56 uncalled functions, at least as many documented uncalled objects, one documented unused type, numerous functions with higher than recommended "cyclomatic complexity,"10 non-descriptive variable names such as "dummy" and "temp," and a buffer overflow. However, in spite of the problems found, SysTest concluded that none affected the reliability of the NJ3.11 firmware breath tests. As opposed to assessment of Base One, the Chun court's expert (CMX) wrote favorably of SysTest's review. CMX found almost all of SysTest's claims were "substantiated," and that its analysis was "impressive" in that it were not only able to run both "code stylistic" tests, through the use of automation tools, (as Base One did) but also a series of logical tests of the application by submitting combinations and permutations of data that would expose the potential buffer overflow condition. CMX also noted that, "[i]n contrast to the Base One Technologies review, the SysTest Labs report is replete with empirical listings and line counts of examples of the conditions, and criticisms they found." CONCLUSION The facts in Chun presented an enormous opportunity to advance the cause of dependable computing. Were the defense able to raise legitimate reliability issues regarding the NJ3.11 firmware, it is likely that the issue of dependable computing would have received increased attention, understanding and respect from the public at large. Unfortunately, however, the defense flubbed this important opportunity. Interested readers who take the time to read the Chun litigation material will likely conclude that the defense accomplished very little with its source code review. Base One's review was contradictory, undocumented, non-empirical, misleading, and speculative. And although the SysTest report was mostly supportive, some will undoubtedly question whether 602 hours of post-hoc analysis, by a manufacturer-contracted expert, is sufficient to guarantee the reliability of NJ3.11 code. Consequently, computer security enthusiasts and genuine dependable computing advocates shall continue to wait for the untutored establishment to understand and to appreciate the importance of proper software quality assurance. 1 Avizienis, et al. "Basic Concepts and Taxonomy of Dependable and Secure Computing," IEEE Transactions on Dependable and Secure Computing, Vol. 1, No. 1, at 13, January March 2004. 2 Kumho Tire Co. v. Carmichael, 526 U.S. 137 (1999). 3 Supreme Court of New Jersey, Docket No. 58-879, available at http://www.risk-averse.com/index_files/chun.pdf. 4 Norman Dee, CMX Group "Comments on the Source Code Reviews," available at http://www.risk-averse.com/index_files/sm.pdf. 5 John J. Wisniewski, Base One Technologies, "Report on Behalf of the Defendants," available at http://www.risk-averse.com/index_files/bo.pdf. 6 Id. 7 Kem Caner, "The Impossibility of Complete Testing," SOFTWARE QA, v.4, #4, p. 28 (1997), available at http://www.kaner.com/pdfs/imposs.pdf. 8 Supra note 3. 9 Supra note 3. 10 In its report, SysTest defined "cyclomatic complexity" as a "standard measure of source code complexity indicative of both understandability and maintainability." See SysTest, "Assessment Report for Draeger Safety Diagnostics, Inc.," available at http://www.risk-averse.com/index_files/st.pdf. Eric Van Buskirk, JD, MA, CISSP
A human accounting mix-up led to the wrong woman being crowned Miss California USA. Apparently lowest points were given to the winner and highest points to the fourth runner-up. Christina Silva, 24, was declared the winner of the annual state beauty pageant, but after the error was detected, she gave up the title to Raquel Beezley, who was originally named the second runner-up. New Miss California Named After Error, The Huffington Post, 3 Dec 2007 [PGN-ed] http://www.huffingtonpost.com/huff-wires/20071203/odd-miss-california Miss California USA: http://misscaliforniausa.com
Peter is Allison's older brother because he was born 34 minutes before her. Yet his birth certificate says 1:32AM on November 4th, while his sister's birth certificate says 1:06AM making her apparently 26 minutes his senior. http://www.wral.com/news/local/story/2011296/
Computer Glitch Leads To Kmart Brawl; 2 People Arrested The store was running a promotion to give away $10 to anyone applying for its credit card, but the computer glitch led to everyone's application being approved, giving up to $4,000 in instant credit to anyone who applied, even if they shouldn't have qualified. http://www.nbc4.com/money/14702622/detail.html?treets=dc&tml=dc_12pm&ts=T&tmi=dc_12pm_1_10500211272007 Gabriel Goldberg, Computers and Publishing, Inc. (703) 204-0433 3401 Silver Maple Place, Falls Church, VA 22042 firstname.lastname@example.org
Some AT&T customers in nine states in the U.S. Southeast were unable to connect to the Internet via DSL for several hours on the evening of 3 Dec 2007, officially ``because of an equipment problem'' -- although AT&T's domain servers were reportedly suspected. Dave Burstein (editor of DSL Prime) is quoted: ``Broadband goes down much more often than telephone lines because they didn't build the system for the same level of reliability.'' Yahoo! News, 4 Dec 2007 http://news.yahoo.com/ [PGN-ed] http://news.yahoo.com/s/ap/20071204/ap_on_hi_te/at_t_outage My own feeling is that the system vulnerability is not the problem. Rather, it is the casual acceptance of the vulnerability and the comparatively lame excuse for it. My guess is that we shall see more stories like this on the broadband front for both wired (e.g. cable) and wireless connectivity. Steve
> Village auto crashes blamed on sat nav Ah! Every time somebody uses a GPS to get to my house, http://maps.google.com/maps?q=24.181706,120.866039&t=h&z=14 they need to pay the local drunk to escort them the 13 kilometers back around the north way, as that fat juicy (to the GPS) south road just doesn't connect! http://maps.google.com/maps?q=24.181706,120.866039&z=15
Please report problems with the web pages to the maintainer