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…
Ameriprise Financial said that lists containing the personal information of about 230,000 customers and advisers had been compromised. A security breach occurred in late December 2005, after a company laptop was stolen from an employee's parked car. The laptop contained a list of reassigned customer accounts that was being stored unencrypted, and treated in violation of various Ameriprise rules. [PGN-ed from *The New York Times*, 26 Jan 2006] [Thanks to Doug McIlroy for spotting this one. Doug remarked on the bad (but seemingly very common) practice, and noted that "a scapegoat has been sacrificed for the company's sins." Also, Bob Heuman cited an item http://ct.enews.eweek.com/rd/cts?d=186-3144-17-83-67263-367596-0-0-0-1 that gave the number of affected clients as 158,000. PGN]
AP is reporting that a house in Valparaiso, Indiana (a town of moderately priced homes) received an $8 million tax bill on a house actually worth $121,900, but appraised at $400 million. This sort of thing isn't unusual, but there were some interesting wrinkles: 1. The change in value was made by a person not authorized to make changes. 2. The value change occurred because the person typed one incorrect letter to access the assessment change application (R-E-R vs. R-E-D to perform the intended action) 3. The assessment change application was (theoretically) no longer in use, having been replaced by a newer version 4. Since tax rates are set as a function of the total assessed value of the property in the community (and an extra $400 million was enough to seriously throw off calculations in this locality), the local government is now significantly short of income, and is laying off staff. This is a great example of a cascading failure - if any one of these steps hadn't occurred (or had a cross-check - such as an audit trail that detected the use of the old assessment program), the problem would not have occurred. The county treasurer says that his office noticed & fixed the error, but somehow it propagated elsewhere too. Article at http://www.cnn.com/2006/US/02/10/overpriced.house.ap/index.html
A little over two weeks ago, I was invited to Google's Los Angeles area facilities in Santa Monica to give an informal talk ("Internet and Empires") on a range of Internet-related topics. Video of that presentation is now available, and since it touched on a large number of our favorite discussion issues in RISKS, I thought it might be of some interest here. The topics naturally included a number of the controversial issues related to Google, but also more generally privacy, free speech, ISPs, data retention, government and legal issues, censorship, network neutrality, and more. The talk ran about an hour and the video will reportedly become available soon as one of Google's "Tech Talks" ( http://video.google.com/videosearch?q=Google+techtalks ). Since the video is not currently online there (and for people who need or prefer other video formats), I have a Windows Media version available now (my thanks to Google for providing me with a video master for processing). Please note that all of the opinions expressed in this talk of course are mine, and should naturally not be construed to represent the views of Google, Inc. Video: http://www.vortex.com/lauren-google-2006-01-24.wmv (Download / ~36MB) http://www.vortex.com/lauren-google-2006-01-24.asx (Streaming) Audio Only (MP3): http://www.vortex.com/lauren-google-2006-01-24.mp3 (MP3 Audio / ~15MB) Lauren Weinstein firstname.lastname@example.org email@example.com http://www.pfir.org/lauren International Open Internet Coalition - http://www.ioic.net +1 (818) 225-2800
The U.S. Air Force said a new employee's e-mail error kept the Pentagon and the public in the dark about nearly $4 billion of its contracts in December. The DoD addresses were dropped from e-mail about more than $1.57 billion for Northrop Grumman Corp., $1.22 billion for Boeing Co. and almost $509 million for Lockheed Martin Corp., involving remotely piloted Global Hawk aircraft and F-22A fighter jets among other contracts. The Defense Department is supposed to announce each business day at 5 p.m. EST contracts valued at $5 million or more for its units, including the armed services. [Source: Jim Wolf, Reuters, 14 Feb 2006; PGN-ed] http://cwflyris.computerworld.com/t/296929/664274/9136/0/
A new U.S. federal government system Grants.gov already costing tens of billions of dollars over its five-year development cycle is intended to be used for all grant applications submitted to NIH, Housing and Urban Development, and 24 other grant-giving agencies, typically giving out something like $400B per year. However, its scheduled widespread use will be postponed because the Windows-based software is not Mac-compatible. In the interim, some applications will require proposals to be submitted from MS systems. One blogger is quoted: "this would be the same government that spent a lot of time and money pursuing Microsoft for its anti-competitive behavior?" [Source: Rick Weiss, *The Washington Post*, 13 Feb 2006; PGN-ed] http://www.washingtonpost.com/wp-dyn/content/article/2006/02/12/AR2006021200942.html?referrer=emailarticle
According to the largest Danish newspaper, Jyllands Posten (known for having first published 10 drawings related to end religion founder Mohammed, in September 2005), the number of attacks on Danish websites esp. for smaller enterprises and private owners raised 10-fold, with more than 900 websites affected in one week. http://www.jp.dk/itogc/artikel:aid=3546652/ (edition: Thursday February 9, 2006) The "simple forms of attacks" (details not given) were accompanied with pro-Muslim statements esp. against publication of Mohammed drawings. Btw: evidently, Jyllands Posten's website is still alive, although some access problems have been reported when the issue was reported in worldwide news (probably shortage of bandwidth). [This is not surprising. However, I think RISKS will stay out of the ensuing brouhaha as being not computer related. PGN]
Re: E-mail and the courts > ... compendium of legal cases in which e-mails play a significant role. > http://arkfeld.blogs.com/ede/email/ And here is one where spreadsheets have caused trouble. http://www.eusprig.org/stories.htm
What to me seems an obvious risk was not mentioned, namely the risk of trusting untrusted software to perform downgrade at all, regardless of the parameterization (e.g., Track Changes disabled) and combination of operations (deletion, overlay, copy) performed. The COMPUSEC field has known and published for decades that software that can downgrade must be trusted and, of course, running on a TCB trusted to the necessary extent as well. Microsoft has perhaps made some progress in the realm of trusted software in the last few years but I doubt that Word or Windows yet meets anyone's notion of highly trustworthy. Curious, I went to one of the references cited, NSA Report # I333-015R-2005, Redacting with Confidence: How to Safely Publish Sanitized Reports Converted From Word to PDF http://www.fas.org/sgp/othergov/dod/nsa-redact.pdf There was a caveat included there to the effect that, "Using original source formats, such as MS Word, for downgrading can entail exceptional risks; the lengthy and complicated procedures for mitigating such risks are outside the scope of this note." Well and good (although it's not the format per se that is the problem but the software that processes it and the TCB it executes on), but there were no references provided in the NSA report to additional sources discussing the inherently "exceptional" risk of relying on untrusted software for downgrade operations, no matter how detailed and convoluted and (one hopes) well tested the redaction operations are. I still think we're misleading people with these band-aid approaches. In the original RISKS article, for example, dmagda states, "these steps give the highest confidence that sensitive information is not hidden in the released document." I don't know why dmagda feels that these techniques provide "highest confidence". Perhaps he or she merely meant that there's nothing better around and these steps are better than nothing. But do they really provide much in the way of confidence in the overall safety of the process? Only to the extent that one trusts Word and Windows to be free of undisclosed Trojan Horses. To not at least more clearly highlight that fact and provide a reference to further literature is a shortcoming in the cited NSA report and the risk is that people may naively assume that since the NSA has published it, it can be relied on with "highest confidence".
Joe Thompson suggested in RISKS-24.15 that the NTSB has "reported on the cause of the Southwest Airlines crash in Chicago" (SWA 1248, Chicago Midway airport, 8 Dec 2005). The NTSB has not reported on "the cause", and probably will not do so for a while (it is likely that there are many causes, not just one. I see at least four from the facts known so far. See below). The investigation is still under way. The NTSB has released a recommendation, A-06-16, concerning the means of calculating landing distances on contaminated runways. I recommend reading A-06-16 at http://www.ntsb.gov/Recs/letters/2006/A06_16.pdf The aircraft landed on a snow-contaminated runway at MDW and overran the runway. It went through a blast fence and onto a public road, where it collided with two cars and killed a young child in one of them. The pilots had used an "on-board laptop performance computer (OPC)" to calculate landing distances to determine whether they could land at MDW in the snow-stormy conditions. The crew inputted weather data and entered runway braking conditions as "WET-FAIR" in the OPC. The OPC calculated that the airplane would be able to land and completely stop with 560 feet of runway remaining. However, "the OPC is programmed to assume that the engine thrust reversers will be deployed on touchdown" and they were not so deployed. They deployed 18 seconds after touchdown. "If the reverse thrust credit had not been factored into the stopping distance calculations made by the OPC, it would have indicated that a safe landing on runway 31C was not possible under a braking condition of either fair or poor" (op. cit. p3). In other words, an implicit assumption made by the OPC program led to the OPC indicating to the pilots that they could land safely on runway 31C when, under the conditions that actually obtained during the landing, the OPC program would have indicated that they could not do so without overrunning. The reasons for the delayed deployment of reverse thrust have not yet been publicly determined by the Board. I have pointed out before in this forum (e.g. RISKS-24.03) that, although the supposedly safety-critical computer systems on commercial aircraft have not yet been implicated in any accident during 18 years in service, the supposedly non-safety-critical computer systems have been causally involved in many fatal accidents. This accident appears to be yet another example. The four causes obviously indentifiable so far are: the weather conditions, the OPC calculation that led the crew to believe that they could land safely on 31C, the crew's decision to land on 31C, and the delayed deployment of reverse thrust. And here we can already see part of the reason why these supposedly non-safety-critical computer systems can continue to be relatively so deadly. There is a crew decision and action interposed between the computer actions (in this case, informational output) and the fatal result. Somehow, we allow greater chances of systems misleading a crew into taking fatal actions than we do that the airplane behaves differently from that which is expected from the crew's control inputs. Put like this, it is hard to see what may justify such apparently incompatible attitudes. But when one looks at the development, it is easier to see how the anomaly comes about. The OPC is probably a much more useful and convenient tool than the paper performance charts which it replaces. There is a legally-blessed principle called GAMAB in France and MGS in Germany which says that one may use a (sub)system B as a replacement for a (sub)system A when one can demonstrate that, in all circumstances of deployment, the risk of using A is at least as great as the risk of using B (usually phrased in terms of the safety of B being at least as great as the safety of A, but "safety" here means the inverse of risk, and there is lower likelihood of misunderstanding if one phrases the principle using the word "risk".) The OPC likely was taken to satisfy the GAMAB/MGS principle in comparison with the paper-based performance charts. Note that, for all we know so far, the accident could well have happened even if the assumption of immediate reverse-thrust had been explicit; for example, the crew had been using paper charts on which the assumption of immediate thrust reverse had been printed. The NTSB focused on the pernicious assumption, not on the means by which it entered the calculation. Peter B. Ladkin, University of Bielefeld, Germany <www.rvs.uni-bielefeld.de>
IMO the conclusion of "automatic" Thrust-Reverser failure is premature -- and probably totally inaccurate. There is yet no reported evidence that the aircraft Thrust-Reversers malfunctioned at all. Human error by the pilot, not failure of an "Automatic" system — is the likely cause of late deployment of the Thrust-Reversers in that Chicago, Boeing 737 accident. The NTSB merely stated that the aircraft flight-recorder showed the Thrust-Reversers deployed 18-seconds after touchdown. There was no statement of actual or suspected failure of the Thrust-Reverser system --- only later than expected activation during landing. The pilot should have 'manually' activated Thrust-Reversers at touchdown. NTSB also states: "During post-accident interviews, the captain stated that he attempted to immediately deploy the thrust reversers but that he was unable to do so. According to the first officer, at some point during the rollout, he noticed that the thrust reversers were not deployed, and he then reached over and deployed them.." Since pilot-error is generally the primary cause of any & all aircraft accidents — IMO it's quite likely the captain failed to deploy Thrust-Reversers... because the co-pilot easily did so, shortly afterward. Perhaps in hindsight the captain honestly believes he "attempted" to deploy the Thrust-Reversers ... or maybe he's now is trying to cover his error by an alleged system malfunction ?? Note that the NTSB has issued neither a preliminary or final report — only an advisory related to flight planning & Thrust-reversers ... so full details are unavailable. Newspaper reports tend to blur important considerations in summarizing the NTSB advisory. Here's the only NTSB reference: http://www.ntsb.gov/Recs/letters/2006/A06_16.pdf
Gary McGraw: Software Security: Building Security In Addison-Wesley, 2006 ISBN: 0-321-35670-5 This book is a "hands-on, how-to guide for software security" for software security professionals. It completes a trilogy together with McGraw's Building Secure Software (Addison-Wesley, 2001) and Exploiting Software (Addison-Wesley, 2004), but it also stands alone as a useful book. It considers best practices for software security in detail, as a fundamental part of the development lifecycle. It is very much in the spirit of what RISKS has promulgated in the past 20.5 years.
BKINSCPP.RVW 20051112 "Information Security: Principles and Practice", Mark Stamp, 2006, 0-471-73848-4 %A Mark Stamp firstname.lastname@example.org %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 2006 %G 0-471-73848-4 %I John Wiley & Sons, Inc. %O U$74.95/C$96.99 416-236-4433 fax: 416-236-4448 %O http://www.amazon.com/exec/obidos/ASIN/0471738484/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0471738484/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0471738484/robsladesin03-20 %O Audience i+ Tech 3 Writing 2 (see revfaq.htm for explanation) %P 390 p. %T "Information Security: Principles and Practice" The preface stresses that the material in this book is intended to provide not only the formal concepts for security, but also advice for the real world. Security is addressed overall, but the work concentrates on cryptography, access controls, and software issues. (The author also adds a discussion of protocols. It is hard to see this as a separate issue, rather than simple implementation details of the other concepts.) The audience is not explicitly stated, but both security professionals and the idea of using the volume as a course text are mentioned. Chapter one is an introduction. Stamp will strike a very sympathetic chord with many support and security people when he adds a requirement to the normal list of security questions: can the system survive "clever" users? A set of problems are given at the end of the chapter. In contrast to the usual "reading checks," these are thoughtful items, intended to determine if the reader has understood the underlying concepts, and to start discussion. Part one addresses cryptography. Chapter two provides the basics, outlining some terms, theory, and history. Functions and algorithms of symmetric key cryptography are explained in chapter three, including some discussion of the controversy over the National Security Agency's role in the development of the Data Encryption Standard. (Stamp points out the weaknesses in the conspiracy theory. It is worth noting that Stamp used to work for the NSA :-) There are some fascinating additions to the usual material for this topic. Asymmetric algorithms and concepts, again with some interesting notes, are given in chapter four. Chapter five deals with hash functions and related topics (and also has a brief mention of steganography). Advanced cryptanalytic attacks are outlined in chapter six. (Those wanting to pursue this topic *will* have to brush up on their math.) Part two looks at access control. Chapter seven provides a reasonably complete look at direct authentication issues and technologies. The material on authorization, in chapter eight, extends the normal view of that topic by pointing out the advantages of capability lists and the fact that our basic security models are actually those of authorization. However, Stamp also includes some technologies, such as firewalls and intrusion detection systems, that have only a tenuous connection to authorization. Part three examines protocols. Chapter nine discusses simple authentication schemes, most relying on some kind of challenge- response system and encryption of some type. Although the writing is clear (and even amusing), Stamp dives into mathematics, sometimes at crucial moments and without fully explaining the base concepts. For real world security protocols, chapter ten looks at SSL (Secure Sockets Layer) and Kerberos, and also examines IPSec and GSM in some depth, pointing out the weaknesses in design. Part four deals with software. Chapter eleven explains buffer overflows and other attacks, and also discusses malware. (Stamp makes a rather odd mistake in calling the third type of malware detection "anomaly detection" rather than the more usual activity monitoring. However, the definition of the term fits activity monitoring properly.) Tamper resistance and software testing are legitimately part of software security, but chapter twelve also deals extensively with digital rights management (DRM) which seems to apply more to data protection. The DRM theme is extended in chapter thirteen which addresses operating system security functions, but also discusses Microsoft's upcoming Next Generation Secure Computing Base, which many feel is more applicable to DRM than any real security needs. An appendix provides an overview of networking, particularly TCP/IP, and network security issues. While not a complete coverage of security, this book has some excellent material on the subjects it covers. With limited exceptions, Stamp's writing is clear, and frequently amusing. (Unlike all too many works that try to inject humour into the security topic, Stamp's quips are not irrelevant or distracting, but often help to address or solidify concepts.) The cryptography section is particularly good, providing items of fairly contemporary cryptological history. The references are well chosen, and a great many are available on the Web, furnishing a rich source of items for further study, or general resources. I can easily recommend this text for those interested in cryptography, and it makes some good points with regard to software security, as well. But you can't have my copy. This one I'm keeping. copyright Robert M. Slade, 2005 BKINSCPP.RVW 20051112 email@example.com firstname.lastname@example.org email@example.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
BKENDSPM.RVW 20051029 "Ending Spam", Jonathan A. Zdziarski, 2005, 1-59327-052-6, U$39.95/C$53.95 %A Jonathan A. Zdziarski %C 555 De Haro Street, Suite 250, San Francisco, CA 94107 %D 2005 %G 1-59327-052-6 %I No Starch Press %O U$39.95/C$53.95 415-863-9900 fax 415-863-9950 firstname.lastname@example.org %O http://www.amazon.com/exec/obidos/ASIN/1593270526/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1593270526/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1593270526/robsladesin03-20 %O Audience s+ Tech 3 Writing 2 (see revfaq.htm for explanation) %P 287 p. %T "Ending Spam" The preface states that the book is for those seriously interested in spam identification technologies, and concentrates on Bayesian and related statistical filtering. Part one is an introduction to spam filtering. Chapter one reviews the history of spam, although many of the early entries are simply annoyances or chain letters rather than the commercial or fraudulent items considered under the banner today, and the author does not seem to realize that 419 scams predated email by a considerable margin. A look at the development of spam filtering (excluding Bayesian) is presented in chapter two, along with some non-filtering. Bayesian analysis is explained in chapter three, and the statistical filtering basis is outlined in chapter four. The fundamental actuarial core is expanded in part two. Chapter five covers message coding. Tokenization, chunking characters into identifiable items, is examined in chapter six. Tricks spammers use to evade filters, and the solutions finding spam despite the deceptions, are outlined in chapter seven. Storage and performance issues raised by the data rules required by statistical filters are addressed in chapter eight. Chapter nine looks at aspects of scaling to systems supporting large numbers of users. Part three deals with advanced concepts in statistical filtering. Chapter ten delves into testing which, because of the individual and adaptive nature of Bayesian filtering, presents unique challenges. Tokenization is revisited in chapter eleven, in more advanced forms. Markovian discrimination, with its examination of stateful entities, is explained in chapter twelve. Having noted many kinds of features in the book, chapter thirteen explores ways to reduce the items used (and data required) while maintaining accuracy. Collaborative rule-building with other users, groups, or systems is reviewed in chapter fourteen. As the preface implies, this is *not* a book for users who just want to install POPFile (although that and other programs are explored in an appendix). For those who are seriously involved in managing and developing spam filtering, however, the book does provide very useful advice, pointers, and research. copyright Robert M. Slade, 2005 BKENDSPM.RVW 20051029 email@example.com firstname.lastname@example.org email@example.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer