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…
Forbes Magazine (9/4/6) included a commentary by Aviel Rubin where he complains about the "Help America Vote Act, which handed out $2.6 billion to spend on voting machines." Avi's recent recommendation is that voters cast only optically scanned ballots that will be randomly audited. But does he go so far as to suggest that voters be allowed to prepare these ballots by hand? Absolutely not. Although I have publicly recommended the adoption of only scanned paper systems since at least 2003, Avi continues to recommend electronic ballot preparation methods, such as described in his Forbes piece, that require all voters to "make their selections on a touchscreen machine." If humans are deemed capable enough to audit ballot counts, they should also be allowed to directly prepare their own ballots without the intervention of a computer. Most voters already do this, since some 60% of US counties and a steadily increasing number of mail-ins (such as in CA, FL and NJ where any voter can register as a permanent absentee) use hand-prepared paper ballots. Sure, modern technology must be available to provide assistance for voters who need or want it, but this does not necessarily have to be limited to "touchscreen machines." Tactile ballots (endorsed by the United Nations, see <http://www.electionaccess.org/Bp/Ballot_Templates.htm>) and mechanical devices (such as the Vote Pad <http://www.vote-pad.us/>) offer inexpensive alternatives that do not require electricity. So, will this advice help America's voters avoid the use of unreliable or insecure voting equipment in 2006, 2007, or even 2008? No, because purchases (costing in excess of $5B, including state allocations and associated long-term service contracts) are already in place. Avi's change of heart (he's previously supported vote-tabulating DREs, see <http://avirubin.com/vote/eac2.pdf>) now favoring optically scanned ballots is simply too little, too late, and his ongoing endorsement of touchscreen voting has made him part of the problem, not its solution. Rebecca Mercuri
I need to set the record straight on one point. Towards the end of her posting, Rebecca states that "[Avi has] previously supported vote-tabulating DREs, see avirubin.com/vote/eac2.pdf" I urge anyone who is interested to have a look at what I wrote in my EAC testimony that she references. It is a scathing critique of DREs. I feel that accusing me of having supported DREs is like accusing Erin Brockovich of having supported water pollution. I have done nothing but argue and fight against DREs from day one. If you read my new book, Brave New Ballot (Random House, 2006), you will see that I have maintained a steady position on this all along. Avi Rubin
A report questioning the accuracy of Diebold Election Systems' e-voting equipment in a recent Ohio election gives more ammunition to critics who doubt the viability of electronic voting technology. A study of 467 of 5,407 e-voting machines used in the 2 May 2006 primary election in Cuyahoga County, Ohio, found that one-third of the booth workers had problems setting up the machines. 45% had problems closing out machines. 38% had problems with printers or spools. 90% of the voters liked the new systems. 10% of the voters reported problems with the machines. [Source: Marc Songini, Paper Trail Flawed in Ohio Election, Study Finds *Computerworld*, 21 Aug 2006] http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyId=13&articleId=9002610
An item in *The New York Times*, 22 Aug 2006 neatly encapsulates the overall state of search engine query data retention issues. http://www.nytimes.com/2006/08/22/technology/22aol.html The observant reader will note that despite the rising tide of concerns regarding search query privacy, the industry as a whole is still pretty much in a state of denial, made all the more confusing by various signals from the U.S. Department of Justice. This is turning into such a mess that it's becoming difficult to even keep the various participants and their positions completely clear. There is every reason to believe that without heroic action by the players involved, we may be heading toward a privacy, legislative, and judicial nightmare. But maybe there's a way out. Let's review: AOL's release of search query data made obvious to everyone what many of us knew all along — that such data contains all manner of personal information, even when the identity of the party making the query is not immediately known directly from usage logs. In the AOL case, the individual query entries were linked by "anonymized" user IDs, but even without such linkages the query items alone can be highly privacy-invasive. The AOL release triggered (as did DoJ vs. Google) broad calls for mandated search query data destruction policies. The personal nature of the AOL query data serves nicely to liquidate the DoJ's arguments (again, as in DoJ vs. Google) that such data is not privacy-invasive so long as the query source is unidentified. The expressed DoJ reasoning is this regard is obviously faulty. Search engine companies have been reluctant to voluntarily dispose of query data on a regular basis. This data has considerable R&D, marketing, and other value. Since the incremental cost of keeping all queries archived forever is so low, there is little incentive within the normal business structure to dispose of this resource, absent overriding considerations. Even while laudably expressing concerns about the potential for third-party misuse of query data, search engine firms (e.g. Google) have proclaimed their intention to keep collecting and saving this data indefinitely. If AOL actually sets in place an aggressive data destruction schedule, it will be something of a watershed event that may (or may not) have broad impacts across the search engine industry. Fears of being placed at a competitive disadvantage will tend to make unilateral moves toward query data destruction difficult to propose or implement. Meanwhile, DoJ is moving in exactly the opposite direction, apparently preparing to propose long-term (perhaps measured in years) mandated data retention schedules, requiring the saving of the very data for which destruction demands are being made in other quarters. DoJ is using child abuse (and as of late anti-terrorism efforts) as their hooks to justify such legislation (please see: http://lauren.vortex.com/archive/000186.html ). This situation has all the elements of a painful and wasteful deadlock, potentially triggering years of litigation while the overall search engine issues continue to fester and become even bigger privacy, business, and political problems. If we wish to avoid this scenario — or at least have a good shot of avoiding it — we need to act now, and we need to do so cooperatively. There are policy and technological approaches to the search query dilemma that can be applied in ways that will serve the interests of all stakeholders. Cooperation and compromise mean that nobody is likely to get everything that they'd ideally want, but to paraphrase the great philosopher Mick Jagger, perhaps we can all get much of what we need. Therefore, I propose the formation of a high-level Internet working group/consortium dedicated specifically to the cooperative discussion of these issues and the formulation of possible policy and technology constructs that can be applied toward their amelioration. Such a working group would be as open as possible, though proprietary concerns would likely necessitate some closed aspects if progress is to be accelerated as much as possible. Participation by all stakeholders would be invited. Representatives of the major search engine firms and concerned government agencies, outside technologists and other persons involved in privacy and search issues, and other entities as appropriate would all play important roles. Of course, it's easy — especially for large corporate enterprises — to simply ignore such efforts and just plow ahead independently. Obviously, without the participation of the key players, the effort that I'm proposing would be useless, and I will not continue to promote it if that situation ensues. However, I suggest that it will be in the long-term best interests, both financially and in terms of corporate and organizational responsibility, for major stakeholders to actively join such a project, since the alternative seems ever more likely to be somewhere between highly disruptive and extremely draconian. Interested? Please let me know. All responses will be treated as confidential unless the sender indicates otherwise. Thank you for your consideration. Lauren Weinstein <lauren@vortex.com> +1-818-225-2800 http://www.pfir.org/lauren Lauren's Blog: http://lauren.vortex.com Co-Founder, PFIR http://www.pfir.org
Centrelink (www.centrelink.gov.au) is the Australian federal government's social security and welfare agency. Staff have access to a wide range of information about Australians. Following a two-year investigation nineteen staff have been sacked for inappropriately accessing the personal information of family, friends and ex-lovers. More than 100 staff resigned when confronted with similar allegations. Five cases have been referred to the Australia Federal Police. The privacy invasions were detected using "specially designed spyware software." While highlighting the risk that sometimes the greatest security threats come from within, at least it's encouraging to see a government department making an effort to crack down on invasions of privacy. More info at: http://www.abc.net.au/news/newsitems/200608/s1721505.htm David Shaw, Senior Software Engineer dshaw@avaya.com
TiVo is starting a research division to sell data about how its 4.4 million users watch commercials - or, more often, skip them: TiVo users spend nearly half of their television time watching programs recorded earlier, and viewers of those recorded shows skip about 70 percent of the commercials. [Source: Saul Hansell, TiVo Is Watching When You Don't Watch, and It Tattles, *The New York Times*, 26 Jul 2006; PGN-ed] http://www.nytimes.com/2006/07/26/technology/26adco.html?ex=1311566400&en=143cb4893c1c45a9&ei=5090
Nickee Sanders reports from Yahoo that: A joint European effort is working on software that would enable remote control of an aircraft that could override any attempts by hijackers to control the plane, and force a safe landing......... The project is budgeted for 36m Euros. Please let us try to get this straight. This comment suggests that the EU is putting 36m Euros into developing control SW for commercial aircraft. This is not so, as far as I can tell. The SAFEE project is a *research* project which is focused on the implementation of onboard threat detection systems and the provision of reliable threat information to the flight crew. In the decision making and response management process, secured air/ground exchange of threat level information is foreseen. SAFEE also anticipates the future use of the European Regional Renegade Information Dissemination System (ERRIDS) by all organizations involved in response to acts of unlawful interference on-board aircraft. ( http://www.safee.reading.ac.uk/about.htm ) Notice that there is no mention of control SW here, but rather of detection systems and reliable information systems. According to the information brochure which one may download at http://www.safee.reading.ac.uk/SAFEE_brochure.pdf there are five sub-projects. One of the five subprojects is "flight reconfiguration: includes an Emergency Avoidance System (EAS) and a study of an automatic guidance system to control the aircraft for a safe return". Notice the wording: a *study*, not writing control SW. One of the other subprojects is concerning with secure air-ground communication. About time. Data exchange between aircraft and ground has been clear-text-based without effective authentication, and it is about time this was changed (I regard authentication as essential). I see one academic partner in the project (the University of Reading) and a lot of commercial partners. Research work by commercial project partners is subsidized to a level of 50%, which means that of this 36m (again note: I haven't checked this figure), roughly half of it will be paid by the participants themselves (the Uni Reading will get 100%). So the risk highlighted by this note turns out not to be the reported one. How to avoid it: check sources before distributing rumors. Peter B. Ladkin, Causalis Limited and University of Bielefeld www.causalis.com www.rvs.uni-bielefeld.de
It is *so* hard to do redundancy on an industrial-scale. I.e., for a large data center. One reason the attempt is so frequently doomed is that is is *SO* hard to test a critical system. Here is a true story of such a failure. I know of a facility has a diesel generator, and even plenty of diesel, enough for easily powering critical systems for a long time. Wanting to be safe they test their generator every month. Time passes. Something goes wrong with the utility power, so the generator fires up. All is running as expected--until the generator stops. Problem: All that diesel. It can't all sit in a gravity-fed tank on top of the generator, most of it is in the big tanks, some distance off, and fed with a pump. Specific Problem: The pump was powered off the utility power not the generator power; works great during monthly tests, but doesn't work well at all when the utility is down.
Lauren Weinstein pointed out the risks of power-failure to "bleeding edge" tech such as VoIP over cable-modem in "Your Cable Company — powered by the guy with the extension cord". Lately AT&T (re-branded SBC) has been running a lot of advertising making the same point, and pretty much suggesting that you are putting your life in danger by switching away from them. Maybe yes, and maybe no. I recently had a 36-hour (_after_ I got home and reported it) service outage on my POTS (Plain Old Telephone Service), as provided by SBC. Clear weather, No power outage. Several of my neighbors had much the same problem, at about the same time, but SBC denied that the truck they had parked over the neighborhood cable vault had _anything_ to do with it. It had to be in my internal wiring (yeah, unable to cope with "no battery", let alone "no dialtone" at the demarcation point). RISK: Assuming that the risk a competitor tells you about is the only one that exists. Why any sane person would go for "Triple Play" is beyond me. Reality: The old "public service" attitude (don't laugh, many PacBell folks did indeed have it) is dead and buried.
Dan Miller asks what happens when you do enter (correctly) an ID for a potentially faulty battery into the dellbatteryprogram.com site. The answer is that the site takes you directly to an order page so that you can request a replacement battery. At least there is no "Are you sure that you want to replace your potentially explosive battery" step. More annoying from my point of view is that I raised a support call with Dell late last month (21 Jul to be precise) as the battery light on the laptop which was normally green had begun to flash an intermittent red light. After a week or so of emails I was basically fobbed off with a normal-operation-for-a-year-old battery story. I now find that this issue had already been made public in a number of sources, and I find it incredible that Dell has been so slow to react. http://www.signonsandiego.com/news/tech/20060712-1221-cargoplanefire.html http://www.boingboing.net/2006/07/28/dude_your_dell_just_.html The BoingBoing story relates how a Dell laptop burst into flames in an office. So far so frightening, but as I work mainly at home and often leave the machine on overnight unattended running AV scans or downloads, in the room next to my daughter's bedroom that I use an office (which of course does not benefit from any of the anti-fire devices that a normal commercial office might have) I find the thought of what might have happened absolutely bloody terrifying. Then, whilst checking the URLs for this note, I come across the story that the batteries were manufactured by Sony and that they knew of these potential problems 10 months ago. Well, after the music CD rootkit fiasco earlier in the year we all know that Sony seems to have a certain contempt for its customers but I think that this latest story takes the biscuit. There's a whole world of difference between compromising the security of a customer's PC , and potentially killing or maiming someone. Furthermore Sony management could perhaps be forgiven for failing to grasp the rootkit issue; they can have no such defence over the rather simple issue that their product might burst into flames or explode. http://www.macworld.com/news/2006/08/21/battery/index.php Lastly, the Macworld story contains the following statement;- "Fujitsu, Toshiba and Hewlett-Packard (HP) said on Thursday that they use Sony Li-ion batteries with their systems, but that the batteries are different from those being recalled by Dell. The companies said they did not see a fire risk for customers and did not plan on doing a battery recall." Anyone feel comforted by that?
I enjoyed reading Dan Miller's "Your Dell laptop battery must be OK!"
http://catless.ncl.ac.uk/Risks/24.38.html .
A new disclaimer has been added to the Dell battery program website:
https://www.dellbatteryprogram.com/
Please verify you entered your PPID correctly before submitting
Common errors include distinguishing between alphanumeric characters:
letter "O" from the number "0"
letter "S" from the number "5"
letter "l" from the number "1"
[This disclaimer nibbles off a little of the pain. But the battery model
number situation reminds me of license-plate confusions, where similar
caveats are presumably issued to police officers. Or, if this ever became
connected with a serious law-enforcement case, might we expect Congress to
seek legislation that makes certain confusion-causing characters illegal,
such as in O0S51I?]
BKITSCPM.RVW 20060808
"IT Security Project Management", Susan Snedaker, 2006, 1-59749-076-8,
U$59.95/C$77.95
%A Susan Snedaker info@virtualteam.com
%C 800 Hingham Street, Rockland, MA 02370
%D 2006
%E Russ Rogers
%G 1-59749-076-8
%I Syngress Media, Inc.
%O U$59.95/C$77.95 781-681-5151 fax: 781-681-3585 www.syngress.com
%O http://www.amazon.com/exec/obidos/ASIN/1597490768/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1597490768/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1597490768/robsladesin03-20
%O Audience i- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P 612 p.
%T "IT Security Project Management"
Chapter one is an introduction, but also something of a preface to the book.
In terms of the intended audience, the author states that it is assumed
readers know the basics of project management and also network security.
The text, therefore, is proposed to be an operational framework for
designing an information technology security project plan. However, as the
material goes on to describe the components of such a plan only network
items are listed: physical security, applications security, databases,
business continuity, and a host of other considerations are notable by their
absence, and even the vital element of policy is buried as a minor
ingredient. There is a vague and verbose outline of risk and cost/benefit
analysis, and a list of success factors that range from the glaringly
obvious (management support) to the counterproductive (standard
off-the-shelf infrastructure is recommended even though this practice is
known to increase the likelihood of attacks).
Chapter two defines security projects, but mostly in terms of the sections
of a proposal. Organizing the project, in chapter three, lists various
project management factors, probably the most significant being the
composition of the team that will define the project. (Didn't we do the
definition in chapter two?) Ensuring quality, in chapter four, seems to
consist of knowing requirements and metrics. Chapter five sees the
formation of the project team, which is not the same as the team that
defined the project in chapter three. Standard project planning advice is
provided in chapter six. Chapter seven is supposed to be about managing the
project, but there is little or no mention of the mechanics of management,
with the content concentrating on initiation and changes of specifications.
The termination phase is reviewed in chapter eight.
Chapter nine, entitled "Corporate IT Security Project Plan," is supposed to
be the promised overarching framework. However, after twenty-two pages of
legal advice (and two warnings about giving or taking unauthorized legal
advice), we find a project outline (missing some of the usual steps) and a
haphazard aggregation of project elements, many of which have been covered
previously. (Contrary to the recommendation in chapter six, the outline
lists a number of items of quite different importance all at the same
level.) A random and unstructured collection of security topics makes up
the bulk of chapter ten, which is nominally about general IT security
planning. The lack of pattern and hodgepodge of subjects seems to confuse
even Snedaker: figure 10-1 on page 265 ("Layered Approach to Network
Security") and figure 10-5 on page 327 ("Elements of IT Security
Requirements") are duplicates. Much the same description is true of IT
infrastructure, in chapter eleven, and it also repeats a good deal of the
content. Wireless security, in chapter twelve, does have more substance
that is specifically related to wireless technology and risks, although it
is strange, given the immediacy of other items in the work (there is a
reference to an event that happened on May 24, 2006), that the list of
802.11 protocols does not list 802.11i, which is probably the most secure.
Chapter thirteen, about operations security, does have a bit more
organization, but is fairly standard advice about incident response,
security awareness, and policy.
If it is expected that the reader is thoroughly familiar with project
management, the primacy and amount of space dedicated to the basic project
operations (chapters two to eight, 158 pages) is odd. It turns out that the
limiting of the technical content to network areas is of no particular
importance, since this volume is really only generic project management
advice anyway (and not overly complete, at that). Page 445 notes that
"[o]ur goal is not to push you to use outside consultants," but Snedaker is
a consultant, and owns a consulting firm. The writing in this book is
turgid, the content banal, and the advice incomplete. Given that I am a
selfprofessed professional paranoid, I may perhaps be forgiven for imagining
that someone might write a bad book in the hopes that readers, attempting to
figure out how to do it themselves, would give up in disgust and look around
for someone to make sense of the process for them.
Just a thought.
copyright Robert M. Slade, 2006 BKITSCPM.RVW 20060808
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org
http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer