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…
Bill Clinton's identity was hidden behind a false name when he went to NewYork-Presbyterian Hospital two years ago for heart surgery, but that didn't stop computer hackers, including people working at the hospital, from trying to get a peek at the electronic records of his medical charts. The same hospital thwarted 1,500 unauthorized attempts by its own employees to look at the patient records of a famous local athlete, said J. David Liss, a vice president at NewYork-Presbyterian. And just last September, the New York City public hospital system said that dozens of workers at one of its Brooklyn medical centers, including doctors and nurses, technicians and clerks, had improperly looked at the computerized medical records of Nixzmary Brown, a 7-year-old who prosecutors say was beaten to death by her stepfather last winter. Powerful forces are lobbying hard for government and private programs that could push the nation's costly and inefficient health care system into the computer age. President Bush strongly favors more use of health information technology. Health insurance and medical device companies are eager supporters, not to mention technology companies like I.B.M. and Google. Furthermore, Intel and Wal-Mart Stores have both said they intend to announce plans this week to embrace electronic health records for their employees. ... [Source: Health Hazard: Computers Spilling Your History, by Milt Freudenheim and Robert Pear, *The New York Times*, 3 Dec 2006] http://www.nytimes.com/2006/12/03/business/yourmoney/03health.html?ex=1322802000&en=b2c0f7946b4e3d9d&ei=5090
> says that the system showed their destination's address as being in > Brentwood in Manchester instead of Brentwood in West London. Looks like another navigational error — the correct destination was Brentwood, Essex, about 25 miles/40km north-east of downtown London; BrentFORD is the suburb in west London. Probably fortunate that the ambulance wasn't headed for Edmonton, north London, or they may have ended up in Alberta! The UK has plenty of traps like this, such as St Ives, Cornwall, being about 270 miles/430km from St Ives, Cambridgeshire. Then there are Tunbridge Wells and Tonbridge, only 5 miles/8km apart but different towns, and not far from Leeds Castle, which is nowhere near the city of Leeds, Yorkshire. Of course localities may have a colloquial name not shown on maps as well. This sort of thing makes for amusing news items, but it can have serious consequences. It reminded me of reported problems with a computer-based despatching system for ambulances in London some years ago, and a quick Google search came up with RISKS-14.48, which included this item: > London Ambulance Service Inquiry Report (long) > <Brian.Randell@newcastle.ac.uk> > a) a need for near perfect input information in an imperfect world; As I understand it, part of the problem was ambiguous or imprecise locations given for incidents; in an emergency situation, callers may just yell out the name of the nearest landmark, or their own name for an area, which may well not match the computer's database. Also this week (7 Dec) came the story of the Kim family who were stranded on remote Bear Camp Road in Oregon, possibly after using an on- line map which did not show the road as unsuitable for winter use, unlike some other paper and on-line maps. Temptation is to blame the map compilers for inadequate warnings. As ever, looks like the way to minimise RISKS when traveling in unfamiliar areas is to get hold of as much information as you can from different sources first, and run a sanity check before you start (what sort of distance/time/hazards are involved?). Cheers, Chris Drewe, not far from Brentwood, Essex County, UK.
This is a very, very tragic story, which perhaps could have been compounded by the possibility that the Kim family may have indeed relied upon bogus online directions in the travels in Oregon over the Thanksgiving Day holidays. http://fergdawg.blogspot.com/2006/12/some-disturbing-news-online-directions.html Thanks to Jon. O. for pointing this out. Our hearts go out to Katie Kim and her family. "Fergie", a.k.a. Paul Ferguson, Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
> 11m pounds wasted because no-one did a decent requirements analysis? This is one tiny aspect of a clearly major problem. The high fraction of huge IT projects which get canceled, often after the entire budget has been spent, is an outrageous failing of the entire IT industry. In fact a significant cause is our time honored approach to requirements analysis. We expect to get the entire set of requirements fixed before the multi year contract is signed. This is absurd. One does not head from St. Louis to New Orleans on the Mississippi River by pointing the boat in the right direction and tying the rudder. Instead we make constant course corrections to stay in the navigable parts of the river. See instead how Tom Gilb approaches such problems in his book, "Competitive Engineering". What we should be addressing is delivering value to (all) the stakeholders. We need to determine the purposes the system is intended to serve and establish some ten or twelve critical and measurable goals. Then we engineer a general approach and find and evaluate a modest set of improvements to address those goals. Finally we pick the lowest cost, highest value phases to implement and test next. Rinse and repeat. Each such phase should be constrained to consume at most a few percent of the project resources before it is delivered to end users (or their proxies) for testing and evaluation. The conventional requirements analysis delivers a shopping list of more than a hundred specific functions for the system. Each function is something that someone thought was a good idea and others signed off without very much analysis and without measurable quality objectives. This results in systems where a large fraction of the required functions, typically thirty to fifty percent, never even get used. What a waste. With the requirements all fixed in advance, there is no opportunity to accommodate the inevitable changes in the world or even to learn from the early efforts in building the system. Experienced project managers learn to control the requests for changes to the specifications by establishing committees to impede their acceptance. Such requirements changes are seen as annoyances instead of being welcomed as course corrections which will yield a more useful and valuable final system. Gilb calls his approach evolutionary delivery, but I prefer to call it extreme incrementalism. In addition to completely eliminating these horrendous massive failures, the method even eliminates the incredible debt burden imposed by denying the users any access to the benefits of the intended system until the completion of the entire years long project. What foolishness. Of course, contractors with experience will claim that their project cannot be done in such tiny pieces. They are wrong, but then they see no need to change their ways since they get paid even for systems which are canceled before they are finished or worse, get completed and then abandoned. The better incremental methods are proven by repeated successes which you can discover at gilb.com and malotaux.nl or by contacting the companies which have adopted their approach in the last thirty some years. Despite these successes, the evolutionary method is still considered radical and risky by almost everyone who has not studied under the masters who developed it and actually applied it to their own projects. Without such radical changes to the way things are done in IT, we can guarantee that RISKS will never run out of such disaster stories. Richard Karpinski, World Class Nitpicker 707-546-6760 dick@cfcl.com NOTE: "nitpicker" in the subject line gets past my spam filters.
Sometime around 1961, a customer of the Bell Labs computing center questioned a value returned by the sine routine. The cause was simple: a card had dropped out of the assembly language source. Bob Morris pinned down the exact date by checking the dutifully filed reversions tests for system builds. Each time test values of the sine routine (and the rest of the library) had been printed out. Essentially the acceptance criterion was that the printout was the right thickness; the important point was that the tests ran to conclusion, not that they gave right answers. The trouble persisted through several deployed generations of the system. BTW, I may have committed a sin 'cos I wrote "reversion" instead of "regression", but neither word was current then — so I seek not remission for going off on a tangent. [This clearly needed an overseeing SineCure. Arc the hair-old angles swing. PGN]
Microsoft Security Advisory (929433), 5 Dec 2006 Microsoft is investigating a new report of limited "zero-day" attacks using a vulnerability in Microsoft Word 2000, Microsoft Word 2002, Microsoft Office Word 2003, Microsoft Word Viewer 2003, Microsoft Word 2004 for Mac, and Microsoft Word 2004 v. X for Mac, as well as Microsoft Works 2004, 2005, and 2006. In order for this attack to be carried out, a user must first open a malicious Word file attached to an e-mail or otherwise provided to them by an attacker. As a best practice, users should always exercise extreme caution when opening unsolicited attachments from both known and unknown sources. ... http://www.microsoft.com/technet/security/advisory/929433.mspx
I drive a 1990 Honda Accord that was purchased used 8 years ago. It's had it's share of minor failures and repairs but has overall been a great car. Yesterday, and at first unknown to me, it had a whopper of a failure. On my way to work a little plastic doohickey that spans the gap between the brake pedal and the brake light switch disintegrated and fell to the floorboard. In normal operation the switch is open when the brake pedal presses against it through the plastic doohickey. When the brake pedal is pressed, it moves away from the switch and that movement causes the switch to close, thus activating the brake lights. So, unbeknownst to me (and I truly dislike being in a state of unbeknowing) the brake lights were in a state of constant on. And furthermore, deepening my state of unbeknowing, the brake lights will operate when the key is not in the ignition. And so they did when I parked my car at my wonderful place of employment, as I was also in a state of inobservance and there were no bells in the car to ring for this particular occurrence as there are for unbuckled seatbelts, as well as headlight switch and key in ignition oversights. At the end of the workday I was relieved of my state of unbeknowing when I approached my car and saw what I thought were tail lights illuminated on the car, signaling apparent stupidity to all who wandered by that day. As I saw the headlights were not on, my state became one of confusion and then of dismay as I tested the ignition and found I would have to beg a jump from a fellow, but smirking, engineer (as I would smirk myself, no doubt, had the situation been reversed). That being done and the car being made to run, on the long ride home I puzzled out that it must be the brake lights that had remained on and not the tail lights. So now I suffer the indignity of appearing to ride the brakes, as though I need two feet to accomplish a chore when one foot will do quite nicely. When home I performed the investigation that revealed the defective part and immediately replaced it with a metal doohickey of similar design and exact function. So a plastic piece breaks on my car and causes the battery to run down? Who'd a thunk of such a risk? Kent Hartfield, Electro Optic Engineering, Lockheed Martin Missiles and Fire Control
We have conducted a study on origin of critical infrastructure failures using 12 years (1994-2005) of RISKS forum data. In this study, we tried to find the causes of critical infrastructure failures and their impacts in different dimensions, such as origin of failures, impacts of failures in spatial and temporal dimensions, their effect on public safety; and how failures propagate from one infrastructure to another. The results obtained from the analysis of real life failure cases, which happened over a considerable time span, should be interesting and useful for RISKS forum readers. Findings of this study have been documented in the following paper: H. A. Rahman, K. Beznosov, J. R. Marti', "Identification of Sources of Failures and their Propagation in Critical Infrastructures from 12 Years of Public Failure Reports", CRIS, Third International Conference on Critical Infrastructures, Alexandria, VA, September 2006. This can be found from the following link: http://www.ece.ubc.ca/~rahmanha/cris2006_CS2_paper.pdf This paper has been selected for publication in the International Journal of Critical Infrastructures. We are presently working on the journal version. We welcome your suggestions/comments about possible improvements (focused more on theoretical aspects). Please send your comments to Hafiz Abdur Rahman <rahmanha@gmail.com> before January 15, 2007. Hafiz Abdur Rahman, PhD Student, ECE, University of British Columbia, Canada Room # 3085 Kaiser Building, Vancouver, B.C. Canada V6T 1Z4 1-604-822-2552
The Seventeenth Computers, Freedom, and Privacy CFP 2007 will take place in Montreal CANADA, 1-4 May 2007. Proposals are due 20 Jan 2007. See the website for details: http://www.cfp2007.org [Stephanie is the Chair this year. I've been to about half of the past CFPs, and it is usually a very thought-provoking meeting, with many RISKS-related issues typically on the program. PGN]
BKIRSGHS.RVW 20060906
"Incident Response", E. Eugene Schultz/Russell Shumway, 2002,
1-57870-256-9, U$39.99/C$59.95/UK#30.99
%A E. Eugene Schultz
%A Russell Shumway
%C 201 W. 103rd Street, Indianapolis, IN 46290
%D 2002
%G 1-57870-256-9
%I Macmillan Computer Publishing (MCP)/New Riders
%O U$39.99/C$59.95/UK#30.99 800-858-7674 317-581-3743 info@mcp.com
%O http://www.amazon.com/exec/obidos/ASIN/1578702569/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1578702569/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1578702569/robsladesin03-20
%O Audience i- Tech 2 Writing 1 (see revfaq.htm for explanation)
%P 384 p.
%T "Incident Response: A Strategic Guide to Handling System and
Network Security Breaches"
Beyond saying that security breaches occur, and that we need to respond to
them, the introduction doesn't tell us much about either the topic or the
book.
Chapter one contains a good deal of material with which security
professionals will agree, but it does not provide helpful guidance. The
attempt to define "incidents" is not wrong in any particular, but is
tautological and of limited utility. "Risk Analysis," in chapter two,
briefly repeats the usual procedures, but expends most of its text in
details of specific (mostly network) system attacks. A suggested
methodology for incident response is provided in chapter three, along with a
justification for the use of a formal process. (Many may find it ironic
that much of the rationale for formal methods has to do with expecting the
unexpected.) (The process is given in the acronym PDCERF; which stands for
preparation, detection, containment, eradication, recovery, and followup;
but the text, rather unsettlingly, presents a number of variations on the
acronym throughout the chapter.) Chapter four deals with forming and
managing an incident response team, and the content is mostly concerned with
communications, corporate culture, and management. This material is
extended in chapter five, which covers other factors involved with
organizing for incident response.
Chapter six turns to a slightly more technical topic, regarding the tracing
of network attacks. This is an overview, with only limited technical
content, but even so a few items are suspect (such as the implication that
MAC [Media Access Control] addresses are permanent and fixed). Legal issues
related to incident response are reviewed in chapter seven. Chapters eight
and nine provide an overview of computer forensics, as well as good advice
on the handling and management of evidence, but at a conceptual, rather than
technical, level. Insider attacks are difficult to determine and protect
against, and chapter ten tacitly admits this by spending a lot of time just
telling stories. Chapter eleven (written by an outside author) examines
criminal profiling and other incident response factors related to social
sciences. Honeypots and other types of deception aimed at the attacker are
the subject of chapter twelve. Chapter thirteen finishes off with a look at
emerging tools and directions.
While still flawed, this work is probably more practical than Mandia and
Procise's law enforcement oriented volume (cf. BKINCDRS.RVW), van Wyk and
Forna's somewhat less detailed work (cf. BKINCRES.RVW), or Schweitzer's
basic and wordy tome (cf. BKINCRSP.RVW) (all, of course, are entitled
"Incident Response").
copyright Robert M. Slade, 2006 BKIRSGHS.RVW 20060906
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org
http://victoria.tc.ca/techrev/rms.htm
Christian B. Lahti/Roderick Peterson BKSOITCU.RVW 20061013 "Sarbanes-Oxley IT Compliance Using COBIT and Open Source Tools", Christian B. Lahti/Roderick Peterson, 2005, 1-59749-036-9, U$49.95/C$69.95 %A Christian B. Lahti %A Roderick Peterson %C 800 Hingham Street, Rockland, MA 02370 %D 2005 %G 1-59749-036-9 %I Syngress Media, Inc. %O U$49.95/C$69.95 781-681-5151 fax: 781-681-3585 www.syngress.com %O http://www.amazon.com/exec/obidos/ASIN/1597490369/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1597490369/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1597490369/robsladesin03-20 %O Audience a- Tech 1 Writing 1 (see revfaq.htm for explanation) %P 333 p. + CD-ROM %T "Sarbanes-Oxley IT Compliance Using COBIT and Open Source Tools" "This book is essentially a technical book, with as much applicable content as we could muster by way of open source technologies and how they fit into the Sarbanes-Oxley sphere of influence." Thus speaketh the authors in chapter one (page 4), giving us, almost immediately, fair warning that there may be problems in this book. For one thing, the Sarbanes-Oxley (SOX) law is *not* technical (if it were, the drafters would have known not to give the central point related to information technology section number 404). The authors seem to be intent on listing off all manner of open source programs, using the magic title of SOX to add legitimacy to an otherwise aimless catalogue. (The use of vague buzzwords is also supposed to increase the perceived erudition of the work, although the authors seem to stumble occasionally, such as when they confuse the French "voila" with the musical "viola" on page 5.) If the authors were truly to answer some of the questions that they pose (for example, is open source software compliant with the law, and can it reduce the costs of achieving and monitoring compliance) then the text might have some utility. However, there is no introduction to the legislation as such, and the list of roles within an organization has little specific relevance to the issues underlying the analysis, integrity, and reporting of financial data. Most of the space in the initial chapter is devoted to screenshots of Knoppix, a poorly explained installation section, and a list of the programs in the eGroupware application. SOX and COBIT are supposed to be defined in chapter two. SOX gets almost no exegesis, while there is a list of some of the COBIT objectives. Chapter three lists various open source security tools, has some random notes on policy and auditing, and a "sample" policy on password change. The usual promotional piece for open source software makes up chapter four, with the standard arguments for using open source, but no new rationale for the application to this particular topic. Chapters five through eight are based on four domains from COBIT (loosely based on the Deming plan-do-check-act cycle). In sequence, we have planning and organization, acquisition and implementation, delivery and support, and monitoring. Each of the chapters has a section entitled "What does [name of domain] mean?" but these questions are not answered in any useful way. Each chapter has an extensive (but not comprehensive) list of tasks that might be undertaken, and each delves deeply into the technical minutia of one or more isolated topics. Chapter nine finishes off with miscellaneous advice in random areas. If you have no experience with security, and are scared stiff of even approaching SOX, this book may get you working on some areas that will probably be useful. Mind you, if you don't get information from other sources, you may find that there are gaps in your security that you never considered. If you are experienced in security, and want to know about SOX or COBIT, and what you should do about them, you will be very disappointed with what you find in this text. If you want to know about open source security tools, you will be even more frustrated. (Having a Knoppix boot CD around might be handy, if you know how to use it.) copyright Robert M. Slade, 2006 BKSOITCU.RVW 20061013 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org http://victoria.tc.ca/techrev/rms.htm
BKKIM.RVW 20061124 "Kim", Rudyard Kipling, 1901, 0-812-56575-4 %A Rudyard Kipling %C 49 West 24th Street, or 175 Fifth Avenue, New York, NY 10010 %D 1901 (no, it isn't a Y2K joke) %G 0-812-56575-4 %I Tor Books/Tom Doherty Assoc. %O pnh@tor.com www.tor.com %O http://www.amazon.com/exec/obidos/ASIN/0812565754/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0812565754/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0812565754/robsladesin03-20 %O Audience n+ Tech 3 Writing 3 (see revfaq.htm for explanation) %P 307 p. %T "Kim" Kipling packed a great deal of information and concept into his stories, and in "Kim" we find The Great Game: espionage and spying. Within the first twenty pages we have authentication by something you have, denial of service, impersonation, stealth, masquerade, role- based authorization (with ad hoc authentication by something you know), eavesdropping, and trust based on data integrity. Later on we get contingency planning against theft and cryptography with key changes. Beyond all this, and repeatedly throughout the story, we have social engineering: misdirection, analysis of situations and characters, the maneuvering and manipulating of people so that they do what you want, all the while thinking that it was their idea. The explanation given is at once subtle and lucid, and is both more useful and much more entertaining than that given by Mitnick in "The Art of Deception" (cf. BKARTDCP.RVW). Kipling is, perhaps, too gentle a writer for the thriller genre. He is, though, a better wordsmith than most of those who work in that idiom. His command of dialogue is unparalleled: in "Kim" there is no need to identify the individual speakers, for they are as instantly distinguished in the text as they would be by speech. I heartily recommend "Kim" to anyone in the security field, or anyone who wants a decent read. copyright Robert M. Slade, 2006 BKKIM.RVW 20061124 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