NASA managers decided on Thursday to skip a launch pad test of the shuttle Discovery's redesigned fuel tank because of the risk the test itself could damage the tank. The test would have entailed filling the shuttle's fuel tank with cryogenic propellants and testing its systems. The fuel tank has been the focus of NASA's shuttle safety upgrades since the 2003 Columbia accident. [Source: Irene Klotz, NASA to skip shuttle tank test ahead of July launch Reuters, 5 May 2006; PGN-ed] There must be a better way. When there's doubt or trouble, skip the test (!?!). There may indeed be some practical wisdom in evidence here, but it doesn't bode well.
In January of this year I reported to British Airways that it was possible to recover arbitrary passengers' confidential information, including Date Of Birth and passport details, by simply matching a frequent flier number to a surname when purchasing a ticket via their website. Since this information is printed on every boarding pass, any discarded passes can potentially provide an attacker with the information he needs to access the data via the website. The problem exists because of the US Government's requirement for airlines to provide Advance Passenger Information for all passengers destined for their shores. It is left to the airlines themselves to administer the data collection systems, and, therefore, to make their own mistakes in the security systems that control access to that data. The more airlines that implement these systems, the more potential security holes will exist. Full story here: http://www.guardian.co.uk/g2/story/0,,1766138,00.html Adam Laurie, The Bunker Secure Hosting Ltd., Ash Radar Station, Sandwich, Kent CT13 0PL UK http://www.thebunker.net +44 (0) 1304 814800 [Joel Baskin also noted http://www.guardian.co.uk/idcards/story/0,,1766266,00.html PGN]
An Open Letter to Google: Concepts for a Google Privacy Initiative Lauren Weinstein May 9, 2006 http://www.vortex.com/google-privacy-initiative Preface: The overall situation relating to U.S. and global privacy issues is deteriorating rapidly. Recent Congressional moves toward legislating broad, government-mandated data retention laws ( http://lauren.vortex.com/archive/000175.html ) are particularly alarming. The manners in which we collectively choose to address these sorts of issues are likely to have drastic impacts not only on our own lives, but also broadly on the shape of society, both today and in the future. Greetings. When I was recently invited to speak at Google's Santa Monica center ( Video at http://lauren.vortex.com/archive/000168.html ), I was impressed by the quality of the facilities, but even more so by the caliber of the Google employees I met during my visit. Google's capabilities are extraordinary. While I have been publicly critical of some Google policies, my concerns have been focused not on Google today, but rather mainly on how Google's immense data processing, storage, and related infrastructures might be abused in the future, particularly by outside entities in a position to force Google's hand despite Google's own best intentions. As discussed in my talk, I consider Google to be an incredibly important and admirable resource with vast potential to do good. But by the same token, it is largely this very power that increases the risks of serious abuses of Google capabilities being forced upon the organization, and Google will likely be unable to mitigate many of these unless it takes major proactive steps on an immediate and ongoing basis, particularly including privacy-related efforts. Increasingly, Internet users are becoming highly sensitized to both perceived and real risks to their privacy associated with their use of the Net. While the real risks we face in this arena are serious enough, people's confidence (or lack thereof) in products and services will in many cases be shaped primarily by perceptions, and often significantly less by the underlying realities. This highlights the critical fact that to be truly successful, efforts to reduce privacy risks must not only have genuine and ongoing positive privacy effects, but also need to be clearly perceived by users and the broader public to be in place and fully supported as primary goals of the organizations involved. Web-based search engines are an obvious current focus of many privacy concerns, but as more traditional "desktop" applications migrate to tightly coupled topologies with user data stored on remote servers not under users' direct local control (e.g. for PC searches, document preparation, e-mail, etc.), these issues and related potential risks are rapidly spreading across the entire computer and Internet spectra. Fears that users' private information may be increasingly subject to intrusive perusal by law enforcement or other authorities (often with minimal and/or questionable cause) are further damaging user confidence in such services, with a range of issues related to data retention being an important element at the heart of these concerns. To the extent that potentially sensitive data is stored for extended periods, particularly in non-anonymous forms, it is inevitable that outside demands for access to it -- on ever broader scales — will be accelerating. While individual court cases will of course vary in their results, the court system cannot be relied upon to always render appropriate decisions regarding such matters, particularly in today's political and legislative environments. I believe that Google, by virtue of its Internet industry leadership, technical and human resources, and corporate culture, is in a unique position. Google can demonstrate how world-class privacy protection policies and technologies can be developed and deployed in ways that enhance user confidence in current and future Google services — by proactively protecting users' private data without interfering with service operations, innovation, R&D, or the legitimate concerns of law enforcement. Google could be the acknowledged global leader in this area, becoming synonymous with the concept of integrating new and advanced privacy capabilities into world-class Internet services and products. Obviously the confidence such efforts would engender in Google's users would be healthy for Google's bottom line, but more importantly it will provide genuine and continuing real benefits to the Google user community itself (i.e. the entire world). Where non-proprietary information is involved, further benefits to society could be achieved through making publicly available (via published papers, conferences, etc.) those aspects of resulting privacy-related R&D technologies that could be deployed by other entities to the benefit of the global community. I recommend that Google establish a team explicitly dedicated to the development and deployment of privacy-related efforts as outlined above. Such a team would be tasked with establishing the framework of these projects in a consistent manner, and ensuring to the greatest extent practicable that all current and future Google products and services would be integrated (from the outset when possible) with these privacy technologies and policies. The team would need access to other individuals within both the development and operational aspects of Google, and ideally would report directly to high-level management. To be effective, such a team would need to be significantly interdisciplinary in its makeup and scope, including a variety of skills. Some of these would include a broad range of CS capabilities (including specialized mathematical disciplines related to encryption, among many others). Experience in dealing with the particular and complex interplay between technology and societal issues will also be an important component of such a team. Google's growing scale and influence suggest that the sorts of privacy efforts suggested herein could be among the most important non-governmental privacy-related endeavors for many years to come, and could have vast positive impacts far into the future not only for Google and its users, but throughout the commercial, nonprofit, and government sectors. This document represents a very brief conceptual outline, offered with only the best interests of both Google and the world at large in mind. Google and the broader Internet are at a critical crossroads in many respects, and I believe that Google has the opportunity to do enormous good by initiating the types of efforts that I've described. I would welcome the opportunity to discuss these concepts with you in more detail and to work with Google toward their realization, as you may deem appropriate. Thank you very much for your consideration. Lauren Weinstein firstname.lastname@example.org http://www.pfir.org/lauren +1(818)225-2800 Co-Founder, PFIR People For Internet Responsibility - http://www.pfir.org
Something of a breaking story (currently being reported by BBC Radio 4's "You and Yours" news magazine program, http://www.bbc.co.uk/ radio4/youandyours/). Shell UK have withdrawn chip-and-PIN credit card payment facilities from 160 of their garages, following incidents of fraud. Chip-and-PIN has been publicised by the vendors as "safer, faster, more secure" than signature-based authentication (see the publicity at http://www.chipandpin.co.uk), although the security of the PIN numbers is the responsibility of the card holders. (This suggests that any fraud which occurs puts the onus on the card holder to prove that the PIN number was not divulged; with the old signature method, the onus is on the retailer to produce the sales slip.) In this particular case, it appears that the card terminal devices designed by Trintech, although tamper-resistant (i.e. will fail to operate if tampered with), were tampered with to commit the fraud. Trintech are claiming that their equipment is not at fault, and the issue is one of the "environment" in which they were installed. I am hoping that this story will be picked up by the science press, so that we can learn some of the details. According to You and Yours, there have been previous incidents of chip-and-PIN fraud where unscrupulous retailers were able to add items to a customer's bill after the payment transaction. nick rothwell — composition, systems, performance — http://www.cassiel.com [Pete Mellor noted a BBC item on this: http://news.bbc.co.uk/go/pr/fr/-/1/hi/england/4980190.stm noting that this situation "rather dents the claim that the introduction of chip-and-pin would dramatically reduce the level of 'plastic fraud'." PGN]
If it really is only the pin that is being encrypted and it is accompanied with the account no - then isn't there an even greater risk of the bank's des keys being considerably more open to attack than in the past? Effectively you have any number of ciphertext samples each corresponding to 4 digit pins, with repeat pins being easily identified by the account no, also each ciphertext has a very limited range of equivalent plaintext (0-9999), and it wouldn't be too difficult to obtain a reasonable quantity of ciphertext with known plaintext by simply opening accounts in the compromised bank.
> In stereotypical and steadfastly arrogant fashion, USA banks are refusing > to move to chip- and-PIN I have heard briefings from highly-placed people at both MC and Visa discussing this. They are steadfast and firm: chips will not be implemented in the US credit cards. There is insufficient justification for the expense, given the cheap modems and phone system available to retail outlets.
The *NY Post* reports that an NY City Police Department (NYPD) deputy inspector was demoted down to captain after NYPD investigators concluded that he had rigged crime statistics when he was in charge of a Queens precinct in 2004. Full story at: http://www.nypost.com/news/regionalnews/63480.htm There have been previous reports of police commanders accused of falsifying the crime statistics (nicknamed "CompStat") in various ways, as they are under great pressure to show "good numbers", even if the criminals don't cooperate by committing less crimes. But this time there's a twist - the former inspector is also accused of "infiltrating the department's CompStat program to increase archived crime numbers for his precinct from before he arrived there" so that his ratings would look even better! I'd love to hear the details about how the NYPD's database was altered - but the Department is rarely that forthcoming with its dirty laundry. They have stonewalled every outside investigation of this problem, especially the Mayor's Commission to Combat Police Corruption, whose chairman quietly resigned after the NYPD refused to cooperate with the Commission. Most of the other reports involve rigging the statistics before the data is entered - felony crimes get "demoted" to lesser categories, and police discourage reports or "lose the paperwork" so that some crimes don't even get into the system in the first place. Even the head of the NYPD Patrolmen's Benevolent Association, the police officer's union, has complained about this. *The Village Voice* published an excellent report that compared the police numbers with similar statistics from local hospitals, showing suspicious drops in assaults reported by the NYPD even though hospital admissions for assault were going up: http://www.villagevoice.com/news/0544,moses,69552,5.htmlhttp://www.villagevoice.com/news/0544,moses,69552,5.html The RISK? The NYPD (and the many police departments worldwide who copy them) have become such slaves of their CompStat system that they spend their effort gaming it rather than doing their jobs and actually reducing crime. [See also my post in RISKS-13.69 describing how the NYPD plays similar computer games with a performance metric in their 911 dispatch system, online at http://catless.ncl.ac.uk/Risks/13.69.html#subj7 ] [Another review of how the NYPD uses technology (including IBM Selectric typewriters!) is at: http://www.baselinemag.com/print_article2/0,1217,a=30781,00.asp (see the two articles "NYPD Rethinks its Dispatch System" and "The Disconnected Cop") ]
Apparently Google has been getting too many "automated" searches on their main site http://www.google.com/ or the personalized page at http://www.google.com/ig/ and has added a "captcha" that you must answer prior to getting to the search page. However, there seem to be some bugs including: - repeated prompts for the captcha (about once per hour so far...) - a frame with customized content is replaced by a Google error message that indicates your machine is possibly spyware or virus infected I find it odd that Google would deploy something that prevents users from seeing all those advertisements that make money from the company (a side effect of doing searches). It would be interesting to find out the back story on this problem and why the "solution" is so broken for users of the search service. [As a follow up, the captcha appears to have been removed after being up about four hours.]
I think this is an issue not only with PBX's, but perhaps to a lesser extent CLEC's as well. I used to work for a business that had a regular need for interaction with the City Police. In Vancouver (BC), if you need the city Police to attend anywhere, even if it's not a 911-type emergency, the only way to reach someone who can actually dispatch a car is to call 911. Thus, I used to call 911 on a semi-regular basis, explain my issue-du-jour to the operator, and get the usual "We'll wander a car by when we have a minute, call us back if it escalates.." But I also got more than my fair share of calls back saying either "We were at 401 West Georgia, and we can't find your business there..." or they'd call back a minute or so later and say "Uh, I thought you guys were over at (location). Our ANI says 401 West Georgia.." We were using Allstream (formerly AT&T Canada), and I guess that their business offices in Vancouver were at 401 West Georgia, and so Telus (the ILEC) had that show up on ANI from thier trunks. I called Allstream repeatedly, and they just kept telling me "Well, we have your address as being (whatever), and so that's what should show up on ANI. There's nothing we can do about it."
The 613 area code (Ottawa and eastern Ontario Canada) is moving from seven digit local calling to 10 digit local calling, a common transition. The first stage seemed to work okay with the caller id now showing the ten digits of local callers' numbers instead of the seven, but this morning, a new glitch appeared. There is a local 866 exchange so that the phone number 866-1234 (just made up) is a local call. As of this morning, when I tried to dial 1-866-123-4567 I received the message "This is not a long distance call." as soon as I pressed the "4" in the sequence. Dialing "866-1234" got me the message "The mailbox of 866-1234 is full." I'm not really surprised. In another several months, when full ten digit calling is required, this clearly will not occur. However, until then, one has to wonder about several issues: (1) Why did Bell, or whoever else is involved, not test the possible effect of this change before it was made in the phone system. It is reasonable to assume that most 1-866 customers are businesses, which implies that this could have a a significant impact on those businesses that rely on their toll free service to receive orders from customers and perform other business functions. The liability issue alone should have flagged this change as one that had to be tested thoroughly. (2) When attempting to contact Bell about this issue, I received one of two responses. Either the Bell operator placed the call for me without listening to why I was calling, or they wanted me to schedule a service call. Finally after a number of attempts, someone at Bell repair finally "got it" and decided to relay my report to their supervisor. When someone reports unusual system behavior (and reports they observed it on several different phone lines) it should raise some sort of red flag. Rod Davison, Critical Knowledge Systems Inc. (613) 834-7018 email@example.com
For those like me who would like to know more about where a link goes before clicking on it, this is the ACLU Pizza flash animation. Also, for those like me who had trouble accessing adcritic's web site, you may go straight to the source: http://aclu.org/pizza/
> Some computer professionals will need to get a Private Investigator license > just to continue doing their computer work. The Ohio law requires this already: The business of private investigation is [...] determine the cause of or responsibility for [...] damage to property, or to secure evidence for use in any legislative, administrative, or judicial investigation or proceeding. > I imagine this will also apply to accountants and auditors The law exempts, among other groups, lawyers and accountants. > We will have to be asking suppliers of firewall, anti-virus, anti-spam, > anti-spyware etc. if they have a PI license Ohio law also exempts licensed professional engineers. Ask your supplier if they employ professional engineers — after all, your software should follow sound engineering principles. My signature line includes "P.E.", which stands for Professional Engineer. Now I know why I got my license... The Ohio private investigator FAQ: http://www.homelandsecurity.ohio.gov/PISG_information/Classes_Licensure.htm Stanley F. Quayle, P.E. N8SQ 8572 North Spring Ct., Pickerington, OH 43147 Quayle Consulting Inc. http://www.stanq.com/charon-vax.html 1-888-I-LUV-VAX
In Wake of SAT Errors, Senator Seeks New Rules on College Testing [Source: Karen W. Arenson, *The New York Times*, 3 May 2006; PGN-ed] NY State Senator Kenneth P. LaValle, chairman of the State Senate's higher education committee, said he would push for stricter government oversight of the college admissions testing industry, including a requirement that all questions and answers be disclosed after the exams without charge.
Several of your recent correspondents seem to need this reminder: "Lead" (pron. "leed") is present tense; "led" (pron. "ledd") is past tense; "lead" (pron. "ledd") is a heavy gray metal. Just to confuse things: "Read" (pron. "reed") is present tense; "read" (pron. "redd") is past tense; "red" (pron. "redd") is a color; "Redd" (pron. "redd") is a guard for the Milwaukee Bucks. Spell checkers will only flag the last item. Richard S. Russell http://richardsrussell.livejournal.com/ 608+233-5640 [NOTE: RISKS cannot be responsible for such errors. Your moderator already fixes many typos, but cannot begin to attempt to overcome the growing general lack of attention to writing correctness. PGN]
BKCISOGG.RVW 20051119 "Governance Guidebook", Fred Cohen, 2005, 1-878109-34-0 %A Fred Cohen http://all.net %D 2005 %G 1-878109-34-0 %I ASP Press %O http://www.amazon.com/exec/obidos/ASIN/1878109340/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1878109340/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1878109340/robsladesin03-20 %O Audience a+ Tech 1 Writing 2 (see revfaq.htm for explanation) %P 204 p. %T "Governance Guidebook" The very short section one of the Governance Guidebook explains that it is intended for the CISO (Chief Information Security Officer) of a large concern. Which is to say that the reader should be experienced in security and the management thereof. At that point one wonders what such a work would entail: presumably such a person would already know pretty much anything you could put into a book. This introduction then goes on to detail the organization of the guidebook. Section two is an overview of the structure of a security plan or protection strategy. It also notes that the illustrations in this section of the text are very busy and cluttered, but that careful study will make the situation clearer. All of this is true. This is definitely not your standard security textbook. It is extremely demanding of the reader, but will amply repay the effort put into using the volume. And I say "using," rather than merely "reading": this is a tome that requires application. Bed- time reading it is not. This is not a primer to be read quickly in one sitting. The illustrations are dense, and so is the text, but dense with meaning and import. This is a work to be worked through, a page or even a paragraph at a time. And then, when you are finished, work through it again. If you are a CISO it won't teach you anything--but it will remind you of things, practices, and procedures that have possibly been forgotten in the press of other urgencies. This volume becomes, therefore, an aide memoire for the strategic planning of information protection. This is not to say that there are no details provided. Section three, entitled "Drill Down," provides greater depth to a number of the areas (one example is an intriguing use of the human life span to address personnel and human resources issues). The content does not deal with specific technical areas of security, but does provide a very solid overview of security management--or, if you prefer, governance. This is a handy and useful guide for those in the CISO position. It is destined to become well-thumbed, dirty, and dog-eared, over time. Those who are not yet into a CISO job will not recognize all of the value in its pages, yet. However, those who aspire to the calling would do well to get a start on learning from it. copyright Robert M. Slade, 2005 BKCISOGG.RVW 20051119 firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer