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…
Two reports published since 2001 pointed to structural problems with the
Interstate 35W. ... The bridge's deck truss system has not experienced
fatigue cracking, but it has many poor fatigue details on the main truss
and the floor truss system. ... In another report two years ago, the
U.S. Department of Transportation's National Bridge Inventory database
concluded the bridge was "structurally deficient."
http://www.cnn.com/2007/US/08/02/bridge.structure/index.html
[noted by Mike Hogsett]
Bridges are generally built with a high level of redundancy, so that if
one part fails the load is distributed through the structure. The I-35W
bridge did not have a high level of redundancy, and the failure of a
single significant component could have led to the collapse of the entire
structure. [Annotation in A Deadly Collapse, a half-page set of graphics,
*The New York Times*, 3 Aug 2007, National Edition A14]
The propagating bridge structure collapse on 1 Aug 2007 in Minneapolis
exposes just one more tip of an iceberg among a large collection of
icebergs. Many of our infrastructures such as roads (some with sink-holes
lying in wait), bridges, railroad track beds, pipelines, storage tanks
(including fuel and nuclear waste), and so on are in serious need of repair,
decommissioning, or replacement. For example, some of road infrastructures
have endured loads far in excess of what was expected in their original
designs and operating environments, and have been steadily declining. This
is just another example of the old adage, "an ounce of prevention is worth a
pound of cure". In this case, the scales are unbalanced by deaths that
cannot be cured and collateral losses.
There is of course a lesson here for information system infrastructures,
Removing information security vulnerabilities seems to be a nonstarter in
the eyes of government and system developers that might otherwise stimulate
remediation. The short-term costs of preventive maintenance always seem to
blind folks to the long-term costs of inaction. This situation reminds me
once again of the importance of farsighted design and continual oversight.
See my two-page note on holistic systems in the November 2006 issue of the
ACM SIGSOFT Software Engineering Notes, in case you have not looked at it
yet:
http://www.csl.sri.com/neumann/holistic.pdf
I seem to have gone all these years of moderating RISKS without citing one
of my favorite multipurpose mixed metaphors: Pandora's cat is out of the
barn and the genie won't go back in the closet. It certainly seems
applicable here.
On 22 Jul 2007, a Polish bus had a grave accident in Vizille (France). The bus used a road with a 14% (1/7) descending slope, it seems its brakes went too hot and could not stop the bus at the end of the slope. The inquiry made appear that the driver blindly followed the indications of is GPS receiver, ignoring the 11 signs forbidding him to use this route. Risk: always relying on technology, even if used a little bit out of spec.
A suspicious looking box found near Lewis-Gale Medical Center [on 19 Jul 2007] was, in fact, a remote weather station that had been affixed to a tree by an employee, and not an explosive device. Constructed with putty and wires, it was probed by the Virginia State Police Bomb Squad — which blew it up before realizing it was a weather station. An employee had placed a putty-like substance around the box to make it weather proof. ... [Source: Annie Johnson, *The Roanoake Times*, 20 Jul 2007; PGN-ed] http://www.roanoke.com/news/breaking/wb/125008
The report that voting machines are not trustworthy is joined by this: RFID passports and readers are vulnerable: http://www.boingboing.net/2007/07/31/hacked_passport_cras.html http://www.wired.com/politics/security/news/2007/08/epassport Hacked passport crashes readers A hacker has demonstrated an exploit against the RFID tags in the new US passports that allows him to clone a passport and modify the RFID with bad code that will crash the passport readers. Lukas Grunwald, an RFID expert who has served as an e-passport consultant to the German parliament, says the security flaws allow someone to seize and clone the fingerprint image stored on the biometric e-passport, and to create a specially coded chip that attacks e-passport readers that attempt to scan it. Grunwald says he's succeeded in sabotaging two passport readers made by different vendors by cloning a passport chip, then modifying the JPEG2000 image file containing the passport photo. Reading the modified image crashed the readers, which suggests they could be vulnerable to a code-injection exploit that might, for example, reprogram a reader to approve expired or forged passports. "If you're able to crash something you are most likely able to exploit it," says Grunwald, who's scheduled to discuss the vulnerabilities this weekend at the annual DefCon hacker conference in Las Vegas.
The Treasury Inspector General for Tax Administration reports that in a recent test of 102 people with direct access to internal IRS data (employees and contractors), 62 of them complied with a request from a caller posing as a technical support person to provide their user name and temporarily change their password. Only eight called the IG's office or IRS security personnel to verify the identity of the caller. Similar tests in 2001 and 2004 were intended to improve security practices, but apparently were not effective. [Source: AP item in *The New York Times*, 3 Aug 2007; PGN-ed] http://www.nytimes.com/aponline/us/AP-IRS-Computer-Security.html
As an infrequent user of Microsoft Windows, I'm often belatedly surprised by its various foibles — new ones seemingly every time I use it — that everybody else saw long ago or is used to by now. Today was no exception. Out of the blue, a dialog box popped up, saying (from memory): Upgrade of your system is almost complete. A restart is required to complete this upgrade. Windows will automatically restart your computer in 3:47 minutes. %%%%%%%%%%%%%%__________________________________________ Restart now Restart later The time 3:47 was continually counting down, once per second, and there was a progress bar showing about 25% complete. There were several interesting things about this message. I had initiated no upgrade, and Windows had not even asked me (as it so often does) if I wanted it to start an upgrade, nor even notified me that one was available. And there was no indication whatsoever (nor any obvious way of investigating to try to find out) what this imposed upgrade actually was. Most significantly, if I had done nothing, my computer evidently would have rebooted, all by itself, in less than five minutes. But of course I had several windows open, containing all sorts of context relevant to the problem I was working on and which I most certainly did not want to log off and lose just then. And I was turning back and forth between the Windows computer and another one; I could easily have turned away for more than five minutes, and missed this charming little dialog box entirely. Naturally I clicked "Restart later", and the dialog box went away. But about five minutes later it reappeared, exactly as before. I clicked "Restart later" again. About five minutes later it reappeared. I clicked "Restart later" again. This went on for the next hour or two. In what universe is this acceptable behavior? I've got work to do; I don't have time for unprovoked restarts; I'd really rather not have to keep a weather eye on a machine so as to be able to repeatedly click "Restart later" just to keep the damn thing up and my work intact. I can't help but wonder what might happen with a machine being used for vital real-time work, or as an unattended server. I do know the answer to the "In what universe?" question, of course: in Microsoft's universe. And I suspect that the update they were so insistent on applying was one for their benefit, not mine. I further suspect I know (although it wouldn't say so) what the whether-I-liked-it-or-not upgrade specifically was. A couple of weeks ago the same machine had been asking me if I wanted to (voluntarily) install and activate another update, namely a more-fully-functional version of its "Windows Genuine Advantage" component. But I had declined that upgrade, because I know that the machine's software is genuine, and I don't want the machine "phoning home" all the time or complaining if it can't, and I certainly don't want it locking me out some day if it ever makes a mistake. I hadn't noticed that it had stopped asking about that earlier upgrade. Perhaps I ought to have been suspicious. Like the back-alley con man who is perfectly happy to rob you if you decline the proffered game of three-card monte, I suspect Windows simply decided to fall back on "Plan B" after I declined the "voluntary" upgrade too many times. That machine is probably now assimilated, and I can feel secure that it is WGA-safe from non-genuine software. Yippee.
I get daily security reports from the hosts I manage. Typically these contain invalid user attempts for users like guest, www, and root. (Although FreeBSD doesn't allow remote logins for root, I was surprised to find out that many Linux distributions allow them.) Today's log surprised me, because it contained only Greek names. Here is an excerpt from the log. Aug 1 00:19:42 istlab sshd[22137]: Invalid user achaikos from 210.17.252.20 Aug 1 00:19:45 istlab sshd[22191]: Invalid user achilleus from 210.17.252.20 Aug 1 00:19:48 istlab sshd[22218]: Invalid user actaeon from 210.17.252.20 Aug 1 00:19:51 istlab sshd[22244]: Invalid user acteon from 210.17.252.20 Aug 1 00:19:55 istlab sshd[22279]: Invalid user adelpha from 210.17.252.20 Aug 1 00:19:58 istlab sshd[22302]: Invalid user adelphe from 210.17.252.20 Aug 1 00:20:01 istlab sshd[22321]: Invalid user adelphie from 210.17.252.20 Aug 1 00:20:04 istlab sshd[22353]: Invalid user adonia from 210.17.252.20 Aug 1 00:20:08 istlab sshd[22387]: Invalid user adonis from 210.17.252.20 Aug 1 00:20:11 istlab sshd[22400]: Invalid user adrasteia from 210.17.252.20 Aug 1 00:20:14 istlab sshd[22417]: Invalid user adrastos from 210.17.252.20 The attack to this host (which is based in Athens, Greece) came from a Hong-Kong-based machine, and the list contained many exotic Greek names while also missing many common ones. Therefore, I doubt that this was a local attack. A Google search revealed that the name list was obtained by merging male Greek names and female Greek names from http://www.20000-names.com. Most probably an attack tool contains lists of names for specific countries (the same site also provides, African, Chinese, English, French, German, Hebrew, Irish, Italian, Japanese, Polish, Spanish, and Welsh names). The tool also maps the IP address of the host it attacks to a specific country, for instance, through the geolocation data of the IP-to-Country databases http://ip-to-country.webhosting.info/. Finally, the attack tool uses the country-specific list for trying to log in to those accounts. Attackers seem to be getting more sophisticated with every passing day. Diomidis Spinellis - http://www.dmst.aueb.gr/dds
I recently signed up for an Amazon Web services account, to try out their S3 service, supplying my credit card number for them to bill me. I played with the service very briefly, enough to incur $0.02 of charges, which appeared in the statement they sent me on Wednesday. Today I received a notification from Amazon that their attempt to charge my credit card had failed (presumably because the amount was too low), and asking if I could amend my account with valid payment method. Hopefully sanity checking will prevail before they start seriously chasing me for the money.
In RISKS-24.35, there was an entry I submitted detailing how Microsoft's Windows Live Messenger service silently filtered out any message containing ".scr" or ".pif", in a very ham-handed attempt to prevent links to trojans from coming through. Even more recently, Microsoft has decided that any IM containing the substring ".info" should be silently discarded. Yes, that's right. In an attempt to combat links to malicious executables hosted on a few random .info domains, they've blocked every reference to an entire top-level domain... and even *that*, as heinous as it may be, isn't the full extent of the block. Sharing a link to an article on www.infoworld.com via Messenger will be a futile effort indeed, for instance. And good luck trying to ask other .NET developers whether MessageBoxIcon.Information is the best icon for a given dialog. The RISKS here are enough to leave one speechless-- in more ways than one! Cody "codeman38" Boisclair cody@zone38.net http://www.zone38.net/
Under the most obvious assumptions about the distribution of "in" vs "out" in disputed calls, that would mean the system was performing worse than chance on its four worst days. That's really not good at all. (There are other plausible distributions, of course. If players object to any call they think has a reasonable possibility of being reverse to their advantage, including some where their objective judgment agrees with the call, that would mean the system was performing seriously worse than chance. If players only object to calls that they think were utterly bogus, the system might well be doing better than chance on disputed calls. Of course, in that case, it might still be doing worse than chance on close shots in general.)
Simple New Voting Protocols provide Ballot Secrecy AND Fraud Resistance
Conventional wisdom says elections with "secret ballots" are protected
against vote-buying and coercion, while elections publicizing the list of
all voters with their votes are immune to fraud — but you can't have it
both ways. In a paper at EVT 07 (Boston, 6 August) mathematicians Ronald
L. Rivest and Warren D. Smith refute that conventional wisdom, potentially
enabling a new level of voting integrity.
"You can have your cake and eat it too with some very simple new voting
protocols," said Professor Daniel Sleator of Carnegie-Mellon's computer
science department. "These are explainable to children. It's surprising
this wasn't thought of 50 years ago."
Previous attempts to create such protocols have "succeeded" in mathematical
senses, but only by employing very complicated cryptographic algorithms,
challenging even for math PhDs. Humans can't vote in those systems without
computer aid, which means that each voter would have to own a small computer
"helper" they trusted to be running correct, unhacked, voting software.
Rivest & Smith's new protocols, called "VAV," "Twin," and "ThreeBallot,"
don't require computers or cryptography, and need only low-tech mechanical
voting devices. In each, voters get take-home "receipts" they can use later
to check their vote was correctly counted — or prove fraud — but which
nevertheless bear absolutely no relation to that voter's vote, hence aren't
helpful for vote-selling.
How can that be? Your take-home receipt in Twin is a copy of a random
_other_ person's vote. In VAV, each voter casts two votes and one matching
"antivote" and gets a copy of one of these three (she chooses which) as her
receipt. Either way, the receipt has no logical relation to that voter's
vote.
All three Rivest-Smith protocols allow "mixing in" old-style unsafe ballots
with the new safe ones. That not only permits happy coexistence with voters
who don't want to use the new system, but also "contagiously protects" even
the unsafe ballots against fraud. "I really love this 'easy upgrade'
feature," said Doug Jones, former chair of Iowa voting systems examiners and
computer science professor at University of Iowa.
The Rivest-Smith protocols work with a wide variety of vote-totaling
systems, not just the "plurality" system most familiar in the USA.
"Plurality is a very poor voting system," said Guy Ottewell, an astronomer
and author regarded as the inventor of Approval Voting in 1968. "We've
known better ones for 200 years." "In plurality voting, it's 'name one
candidate then shut up'," said Ottewell. "With Approval, you name _all_ the
candidates you 'approve.' It's actually simpler because there is no special
rule outlawing 'overvoting,' and it both delivers more information in each
vote and allows voters to approve their true favorite without being
strategically foolish, so it's also more honest information."
But why would voters want dishonestly to vote for someone other than their
true favorite? "Two words," said Ottewell. "Ralph Nader." "With approval
voting, Nader voters aren't a problem, they're beneficial."
But Ottewell and Smith now instead advocate "Range voting," essentially the
system used in the Olympics: as their vote, voters score all the candidates
they want to within some fixed score-range (say 0 to 9); highest average
wins. (Range becomes the same as Approval if the range is 0 and 1.)
"Honeybees have been using range voting for millions of years, and my
computer simulations indicate it outperforms every other common
vote-totaling proposal," said Smith. ###
MORE INFO:
Fuller Story (including how VAV & Twin actually work):
http://RangeVoting.org/RivSmiPRshort.html
Rivest-Smith actual paper: http://www.math.temple.edu/~wds/homepage/tb8.pdf
also in html: http://rangevoting.org/RivSmiTB.html
Addenda to the paper: http://rangevoting.org/RivSmiTBadd.html
Follow-up stories: http://rangevoting.org/RivSmiPRfollow.html
EVT 07 Conference: http://www.usenix.org/events/evt07/cfp/
Center for Range Voting: http://RangeVoting.org
Dr. Warren D. Smith 631-675-6128 warren.wds AT gmail.com (prefer email)
http://www.math.temple.edu/~wds/homepage/works.html
*Approval & Range voting (AV & RV):
Guy Ottewell +1297-442247 guy AT universalworkshop.com
http://www.universalworkshop.com
*(AV, RV, and also most other vote-totaling systems too)
Prof. Steven Brams, NYU politics dept. 212-998-8510 steven.brams AT nyu.edu
(co-author of book "Approval Voting") FAX: 212-995-4184
*Computer Science:
Prof. Daniel Sleator, CMU CS dept. Office ph 412-268-7563, fax: 412-268-5576,
home ph: 412-HACKERS
BKIMITIL.RVW 20070228 "Implementing ITIL", Randy A. Steinberg, 2005, 141206618-2 %A Randy A. Steinberg RandyASteinberg@aol.com %C Suite 6E, 2333 Government Street, Victoria, BC V8T 4P4 %D 2005 %G 141206618-2 %I Trafford Publishing %O 888-232-4444 FAX 250-383-6804 sales@trafford.Com %O http://www.amazon.com/exec/obidos/ASIN/1412066182/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1412066182/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1412066182/robsladesin03-20 %O Audience i- Tech 1 Writing 1 (see revfaq.htm for explanation) %P 489 p. %T "Implementing ITIL" Chapter one notes that there are problems in how information technology (IT) works in supporting the enterprise. Steinberg does mention that there should be better integration of the various parts and functions of IT service, that IT service management (ITSM) should be performed better, and that the Information Technology Infrastructure Library (ITIL) is a framework for improving ITSM, but does not, at this point, define either ITIL (and never does explain ITSM). Nine general principles for success are listed in chapter two. The precepts are sound (such as targeting the "Pareto" processes that are going to give you the best results for least effort), but vague: there are almost no details on how to accomplish this wonderful state. Chapter three provides a generic and rather terse outline of a general project management cycle, under the heading of a process for implementing ITSM over a period of a year. Modification of the culture of a corporation is a massive and difficult task: the suggestions in chapter four have some interesting and useful detail in regard to communications, but disregard the challenges involved. A catalogue of roles for large teams and projects is given in chapter five: this is probably too large for most ITSM ventures. Chapters six through eleven outline the general stages in a project cycle, albeit with idiosyncratic names for most phases (and missing a few steps, such as requirements definition, testing, post- implementation assessment, and maintenance). The material is reasonable, although quite terse and vague. A great deal of space is devoted to forms, checklists, and questionnaires. These would probably be quite useful as templates for those involved in an ITSM improvement project, but would have to be refined for a specific situation. "Vision," in chapter six, is basically the project concept or initiation phase. "Assessment" is given a separate chapter (seven), but seems to be part of the concept definition. Planning is in eight, and implementation in nine. "Initial wins" are described, in chapter ten, as small, quick projects that provide some early "high" returns on the efforts. The text outlines a management cycle for small projects and so duplicates a good deal of material that was presented earlier. There is also a list of initial win projects, although the value of most is questionable and they would have to be carefully reviewed for a specific environment. "Control work," in chapter eleven, is partly implementation of small projects, partly overall project documentation and management, and lots of workflow model charts: the content is rather a mixed bag. Chapter twelve finally gets around to some details of ITIL: the text does, rather briefly, present the topical areas (known, in ITIL parlance, as processes) of the management of incidents, problems, change, release (of software), configuration, service levels, availability, capacity, continuity, finance, the service desk, and security. A poorly explained and formatted two-dimensional chart of the information flow between processes makes up chapter thirteen. Various software utilities and their bare-bones functions are listed in fourteen, while fifteen mentions miscellaneous documents related to the ITIL processes. Chapter sixteen has a terse catalogue of roles and job descriptions for the processes. Guiding principles are defined, in chapter seventeen, in a way that is very similar to vision or mission statements, albeit with somewhat more detail. (ITIL is a decent overview of the provision of IT services, but note that it has gaps. For example, incident response is seen only in terms of customer service, without any relation to security. Security management has solid and important directives on management, a holistic approach, policies, and audit, but when it comes to the actual provision of controls, the advice is to have proper ones, without much detail on what those might be.) The title of the work is somewhat misleading. The largest part of the book has to do with generic project management. ITIL does get some presentation, but not until the book is more than half over. In addition, the work is poorly structured and written. The end of chapter sixteen, as one example, talks about roles for "ICT," but ICT is not defined until the end of chapter seventeen (and then only as "Infrastructure Control"). The material is not complicated, but the writing is frequently unclear, and it is only the simplicity of the basic concepts that prevents the reader from getting lost. (Sometimes the writing is completely off the wall. "Fix just one IT service problem per day and within 90 days you will have made 107 service improvements" is clearly self-contradictory.) For those who have not done much in the way of project management, there are some helpful guides that will get you going (although you will need to check in other references such as Scott Berkun's "The Art of Project Management" [cf. BKARPRMA.RVW] or "Applied Software Project Management" by Stellman and Greene [cf. BKAPSWPM.RVW] in order to deal with the missing bits). For those not familiar with ITIL, chapter twelve is a reasonable introduction. For those working to improve ITSM within their enterprises you will probably need a bit more help than is provided herein. copyright Robert M. Slade, 2007 BKIMITIL.RVW 20070228 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