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…
More details have emerged on the EON Austria-to-Spain power outage since in
RISKS-24.47 (which erroneously stated rather absurdly that 82 million
Germans were affected, instead of the previously noted 10 million
Europeans).
Axel Eble cited the original German text of the E.ON Netz report:
http://www.eon-energie.com/php/pressemitteilungen/download.php?id=49602
Jaap Akkerhuis <jaap@NLnetLabs.nl> cited the E.ON report in English:
http://www.eon-energie.com/php/pressemitteilungen/download.php?id=54598
The upshot is that the initial calculations for the planned shutdown showed
the link over the Ems River could be compensated for by rerouting
alternative power. The so-called "N-1 criterion" for stability was
correctly applied initially, but not reapplied after the reconfiguration.
Thus, the second-order effects of the shutdown were ignored — namely the
increased loads that would result from the rerouting — and the Norwegian
Pearl was allowed to pass.
From the English language version of the report (which explicitly notes that
the German version shall prevail in case of any discrepancies), the summary
states that "the determination of demands that can actually be met and which
the market participants demand of the grid must be continuously be reviewed
in a close dialogue between grid operators, grid customers, regulating
authorities and political forces." [*]
Continuing from the summary, "Finally, it also remains to be stated that the
concrete incident has no connection with issues of grid investments. It
must, however, be clearly stated that the growing demands on the grid can
only be met — in the long run — by a corresponding expansion of the grids."
Once again, we are confronted with the risks of short-term/global
optimization.
[* NOTE: As a rather PGN-ish aside, Webster maintains that a "dialogue" can
be BETWEEN N entities, where N may be two or more. However, when I learned
English, it was customary to make a distinction between "between" and
"among" (for N=2 and N>2, respectively). This seems to have fallen by the
wayside over time. On the other hand, German uses one word ("zwischen") to
cover both, as do French/Spanish ("entre") and Russian ("myeshdu"). At any
rate, the concept of a CLOSE DIALOGUE BETWEEN (or even AMONG) N entities
seems suspect when N is considerably greater than 2, as it is in the
European community, and when communication is inherently NOT CLOSE. I think
that the choice of the German text ("im engen Dialog von ...") is itself
misleading, and that the English translation could have been more accurately
rendered as "in close multipartite communication among ...". Why do I
engage in such semantic blather? Because the lack of CLOSER COMMUNICATION
is often a serious source of risks in many RISKS episodes, and Conway's Law
and generalization thereof keep resurfacing as representative of fundamental
problems that arise from restricted communications. (Wikipedia has a nice
discussion of Conway's Law, which relates difficulties in communication
specifically to corresponding flaws in software developments. However,
certainly someone must have cited its obvious generalization to other types
of systems. Surprisingly, I don't think I've mentioned Conway's Law
previously in RISKS, although I have been referring to it explicitly and in
its generalized forms for many years. Melvin, not John.) PGN]
Sunday morning, Nov. 26, 2006 there was a power outage in Hamburg-Lokstedt, where the German TV station NDR has its headquarters. This time it was Vattenfall, not EON that was responsible for the power-out. Both the regular medium voltage and the emergency power system were knocked out. It took about 90 minutes for broadcasting to be completely resumed. http://www.netzeitung.de/medien/455451.html with links to other reports This is the second time in one week that a TV station has dropped out of the ether, last week both Hamburg 1 and ZDF were offline after a power outage in Hamburg-Rothenbaum. NDR itself explains at http://www1.ndr.de/ndr_pages_std/0,2570,OID3392462,00.html that it was not actually a power outage. Ivo Banek, a speaker for Vattenfall, said that there were numerous short-circuits in the 50 km long cable in Lokstedt. It happened in the span of a few milliseconds, and normal electrical customers will not have noticed anything. This brought down the electricity for the TV station, however, and a ground fault brought the emergency power system to its knees. It is still not clear what caused the shorts. Prof. Dr. Debora Weber-Wulff, FHTW Berlin, Internationale Medieninformatik, 10313 Berlin http://www.f4.fhtw-berlin.de/people/weberwu/ +49-30-5019-2320
MPs will hold an inquiry into 12-billion-pound NHS IT plan after some MPs
expressed concerns that the scheme may be foundering. The decision reverses
a resolution taken by the parliamentary committee only weeks ago not to hold
an inquiry, and vindicates a campaign led by leading academics. [Source:
Tony Collins, *Computer Weekly*, 28 Nov 2006; PGN-ed]
http://www.computerweekly.com/Articles/2006/11/28/220206/mps-will-hold-inquiry-into-12bn-nhs-it-plan.htm
[Brian has been involved in this campaign to get an inquiry held into the
problems arising in connection with the National Health Service National
Programme for IT ("NPfIT", which strangely reminds me of Tom Lehrer's
Boston subway song punchline — "HCKC-PW"). He is pleased to report that
they have had some success. PGN]
[Brian also reports that the public dossier (http://nhs-it.info/) that
he edits on this subject continues to grow. This is an extraordinarily
good analysis, and well worth reading. The RISKS-related lessons are
profound, although unfortunately not unusual. PGN]
In the last few weeks, I've done quite a bit of flying, and twice, now, I've been on planes where they had to reboot. The first trip where this happened, as we were scheduled to leave the gate, there was a delay, and then the pilot said over the intercom: "We're having trouble with some of the cockpit instruments, so I'm going to force a hard reboot by switching off all the power for a bit." The lights and all other power on the plane then went off, and after a fifteen second pause, on again. A minute later, the pilot said: "That seems to have fixed the problem," and we were off. I wasn't impressed. As far as I am concerned, this is clear evidence of a genuine design error somewhere in the system. The second problem happened on Sunday, on a flight back from Amsterdam. On that flight, they had serious problems with the in-flight video on demand system. They tried a "soft reboot" of some kind, and it didn't work, so they then tried two "hard reboots," their term, and after the second try, it worked fine. Their instructions were "until the system comes all the way up, please don't touch any buttons." That alone suggests poor design. The system ought to come up with interrupts disabled on any devices that it's not ready to listen to, after all. The reboot process took close to half an hour, and watching the displays in the seat backs that were visible from my seat, I could see that they were being rebooted in sequence, about one per second. Furthermore, as each in-seat display was rebooted, it showed the Linux penguin and then a Linux boot script, revealing that each seat-back display was a little Linux system, suggesting that they were all networked to a video server for the plane. Again, the need for these global reboots is strong evidence that the systems were not well designed, I wonder if both of these stories illustrate problems with the kinds of graduates we are turning out these days. CS programs across the country are emphasizing high-level courses in web programming, but fewer and fewer students know anything about the fundamentals of parallel programming that underly things. So, in constructing the kinds of distributed applications that show up in contexts like streaming video and cockpit instrumentation, they are working without the theoretical underpinnings needed to understand the problems they encounter.
A British ambulance crew, transferring a patient to a hospital where they had never gone before, drove 200 miles out of their way before realizing that their satellite navigation device had given them the wrong directions. These reports http://www.timesonline.co.uk/article/0,,2-2482605,00.html http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=419836&in_page_id=1770 mention other incidents of sat-nav gaffes, but don't say what the actual error was this time; this shorter one http://www.thesun.co.uk/article/0,,2-2006551015,00.html says that the system showed their destination's address as being in Brentwood in Manchester instead of Brentwood in West London. The patient was not harmed, and the crew has been told they should have known better. Mark Brader, Toronto, msb@vex.net
On the eve of "Black Thursday", the Russian banks' liquidity crisis of August 1995, Anton Dolgov, the head of the Moskovsky Gorodskoi Bank, disappeared leaving debts of around $100m. Since then he had been hiding under many aliases. On 30 Nov 2006, he appeared in a London court, reportedly the head of an international identity theft gang that had defrauded thousands of account holders out of millions of pounds over a period of 10 years, using compromised credit cards, false documents, and a bogus law firm. Dolgov pleaded guilty to four conspiracy charges. [Source: David Pallister, 1 Dec 2006, *The Guardian* (UK); PGN-ed] http://www.guardian.co.uk/crime/article/0,,1961441,00.html School of Computing Science, Newcastle University, Newcastle upon Tyne, NE1 7RU, UK http://www.cs.ncl.ac.uk/~brian.randell/ +44 191 222 7923
My large eastern bank abandoning the vendor servicing their Visa credit cards and bringing the task in-house. They sent out forms which we must fill out and sign in order to accept this situation. The top of the form says "For your Visa card ending in 9999". The form has out name and address and an "acceptance code" pre printed. Yet they ask for the end user to manually fill in: SSN, date of birth, mothers maiden name, and home phone, plus they want you to enter your existing (still valid) credit card number!!!! So on one small piece of paper, they create the perfect identity-theft kit, with information they already have on file. While one piece of information might be necessary for me to prove who I am to accept this offer, I am sure their fraud department will be busier than need be in the near future.
A system widely used by U.S. banks to process large volumes of payroll, credit and debit card transactions experienced intermittent outages on 27-28 Nov 2006, possibly due to some sort of malfunction or communications failure in portions of the Federal Reserve's "automated clearing house" (ACH) network, according to Security Fix — which received an anonymous tip from an individual who claimed to work at a mid-sized bank that experienced trouble transferring ACH files across the Fed's network. [Source: Brian Krebs on Computer Security, *The Washington Post*, 28 Nov 2006; PGN-ed with thanks to Jim Horning for spotting Brian's blog, which gives further details.] http://blog.washingtonpost.com/securityfix/2006/11/federal_reserve_ebanking_syste.html
Greetings. A story is making the rounds right now regarding FBI use of cell
phones as remote bugs (e.g. http://news.com.com/2100-1029-6140191.html). I
originally wrote about this concept in my PRIVACY Forum in 1999 ("Cell
Phones Become Instant Bugs!" - http://www.vortex.com/privacy/priv.08.11) so
the issue is real, but we still need to bring the current saga back down to
earth.
This discussion doesn't only relate to "legal" bugs but also to the use of
such techniques by illegal clandestine operations, and applies to physically
unmodified cell phone hardware (not phones that might have had separate,
specialized bugs physically installed within them by third parties) ...
[ Full article at: http://lauren.vortex.com/archive/000202.html ]
You can read the whole thing here: https://bugzilla.mozilla.org/show_bug.cgi?id=330884 In a nutshell, the password manager can save or not save passwords for individual sites. He secretly visited many dating sites and wisely selected "don't save password." She happened to see the list of "don't save password" sites in the configuration. They are no longer engaged. Mark Lutton, Business Intelligence Services, a Thomson Business
http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyId=17&articleId=9005379 http://www.info-svc.com/news/11-21-2006/ http://secunia.com/advisories/23046
BKPHSHNG.RVW 20061014 "Phishing: Cutting the Identity Theft Line", Rachael Liniger/Russell Dean Vines, 2005, 0-7645-8498-7, U$29.99/C$38.99/UK#18.99 %A Rachael Liniger %A Russell Dean Vines %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 2005 %G 0-7645-8498-7 %I John Wiley & Sons, Inc. %O U$29.99/C$38.99/UK#18.99 416-236-4433 fax: 416-236-4448 %O http://www.amazon.com/exec/obidos/ASIN/0764584987/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0764584987/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0764584987/robsladesin03-20 %O Audience i+ Tech 2 Writing 2 (see revfaq.htm for explanation) %P 309 p. %T "Phishing: Cutting the Identity Theft Line" The introduction to the book provides a good, and very realistic, prologue to the topic of phishing. The audience for the work is said to consist of executives and incident response teams for banks and large corporations, information security professionals, and general Internet users. Chapter one furnishes the reader with a solid overview of the subject, although it would seem to be aimed primarily at individual Web and email users. "Phishing Emails," in chapter two, explains various spam hiding and URL obfuscation technologies. The list is not exhaustive, but is sufficient to illustrate the basic concepts clearly. (The writing, in this chapter by Rachael Liniger, is delightful. Wit and humour are used extensively, and to good effect.) Chapter three presents information on false or obfuscated URLs, as well as useful detail on pop-ups: the content is much superior to other sources on the same topic. (There is also an oddly placed section on public key encryption.) Spyware is reviewed in chapter four. You cannot stop phishing completely, notes chapter five, examining various players in the fight against identity theft and the limitations of the action they can take. Chapter six is supposed to be about helping the organization to avoid phishing, and sets forth some policies in regard to email and Websites that are very practical in preventing abuse. (The section on authentication schemes is less so, and eventually the chapter devolves into random topics.) A generic and sometimes terse outline of incident response and network forensics makes chapter seven poor in relation to other parts of the book. In terms of consumer education, chapter eight has a number of recommendations for safer computing, with lots of "avoid Microsoft" advice, but also configuration settings, a bit of email analysis material, and an admonition to check your home finance statements carefully. Chapter nine deals with actions to take if you, personally, are the victim of identity theft. (Most of the agencies mentioned are based in the United States, but the resource list does have some additional contacts for the UK and Germany.) Identity theft (and, by extension, phishing) is a major problem, and not enough is being done to address the issue. This book lays out the risks and threats clearly, and proposes practical solutions for a variety of actors in the drama. The text is readable and the concepts are clear. I can recommend this work to almost anyone involved in a security role, particularly those in the financial or online industries, law enforcement, or working in the field of security awareness. copyright Robert M. Slade, 2006 BKPHSHNG.RVW 20061014 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org http://victoria.tc.ca/techrev/rms.htm
BKSCRAHB.RVW 20060919 "The Security Risk Assessment Handbook", Douglas J. Landoll, 2006, 0-8493-2998-1 %A Douglas J. Landoll %C 920 Mercer Street, Windsor, ON N9A 7C2 %D 2006 %G 0-8493-2998-1 %I Auerbach Publications %O +1-800-950-1216 auerbach@wgl.com orders@crcpress.com %O http://www.amazon.com/exec/obidos/ASIN/0849329981/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0849329981/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0849329981/robsladesin03-20 %O Audience a Tech 2 Writing 1 (see revfaq.htm for explanation) %P 473 p. %T "The Security Risk Assessment Handbook" Chapter one is an introduction. Landoll's text is initially rather preachy and biased. The first couple of sections appear to take the position that industry has failed in its responsibility to secure information systems, and therefore (the United States federal) government has had to take charge. He then lists (although does not describe in any detail) various security frameworks and guidelines, and argues that, simply on the basis of a lack of congruence between these documents, "best practices" are a myth. His conclusion, that risk-based security planning is better, seems oddly gleeful in the context of such an otherwise dour piece of writing. Unfortunately, the author does not seem to do any better with risk-based security planning, right off the top. We are told (on page four) that "the establishment of an information security program is not the topic of this book. The topic of this book is how to perform and review an information security program," which statement(s) must surely rank highly in terms of self-contradiction and confusion. Were the reader to quit after this inauspicious, muddled, and verbose beginning, however, it would be to miss a work of some value. Within pages, Landoll clarifies the rationale for, and types of, risk assessment, as well as explaining the purpose of this volume in light of other existing assessment tools and documents. (To his credit, where other authors tend to denigrate alternative references, Landoll notes their respective strengths, and then states the extension that his book provides.) It is frustrating to attempt a single assessment of the book. The text has value, but also annoyances. Chapter two provides a useful guide to the basic components of the risk assessment process (which forms the structure for much of the rest of the book). At the same time, where Landoll has been using the business-oriented breakdown of control types (into administrative, technical, and physical), when discussing safeguards he suddenly switches to the categories of preventive, detective, corrective, et cetera, that are more familiar to those in the government and military. (Interestingly, for someone from a strongly governmental background, Landoll does not fill out the list with recovery, compensating, deterrent, and directive.) In addition, when reviewing the concept of residual risk, two new terms of "static" and "dynamic" risk are introduced. Although the terms are poorly defined, "static" seems simply to refer to residual risk, while "dynamic" appears to mean nothing more than risk itself. Therefore, these two new entries provide no distinct value to the discourse, and only serve to confuse the issues. Again, chapter three covers the vital topic of the definition of objectives and scope of a risk assessment project. When discussing the "customer" for a review, "Risk Assessment Method" and "Objective Review" seem to be presented as potential clients. While the question of quality of work would certainly appear to be a legitimate concern in dealing with project extent, Landoll includes a great deal of material relevant only to the final report, such as grammatical correctness and visually pleasing presentation. On the other hand, there is a good deal of very practical content addressing issues of realistic scope and reasonable budgeting. The preparation phase is covered in chapter four, dealing both with practical issues such as letters of introduction, more esoteric concerns of system and asset criticality, and also reviewing a number of methodologies and approaches to risk assessment (although primarily at a conceptual level). Chapter five starts a string of chapters on various types of data collection. It leads off with general discussions on the topic, examining questions of sampling and related issues. (Landoll is not always careful about explaining terms before starting to use them: neither the index nor any part of the text notes that the RIIOT method, which is used extensively in the chapter, is merely an acronym for the phases of review, interview, inspect, observe, and test.) The gathering of data on administrative safeguards, in chapter six, has good checklists of items to assess, and uses the RIIOT format to structure the areas and phases of the elements to consider. (There is a rather odd reluctance to discuss policy, and an even stranger overemphasis on two-man controls.) Moving into technical countermeasures, chapter seven starts off with a section on attacks and controls. There are very odd errors in the text: the distinction between SPAM (the Hormel food product) and spam (bulk unsolicited commercial or fraudulent messages) may be subtle but every security specialist should know it and yet Landoll uses SPAM throughout. The section on antivirus protection is weak, cross-references are spotty, and Landoll uses an old (and generally abandoned) type of firewall (session-level, which is an amalgamation of stateful and circuit-level proxy). Intriguingly, authentication is not addressed with technical controls, but (rather weakly) with physical protection, in chapter eight. Most of the discussion of physical security outlines particular safeguards, and there is little deliberation on risk assessment or the factors that can influence it. (For example, various power supply alternatives are discussed, including the rather esoteric flywheel generator, but the idea of requesting information from the utility on past power outages doesn't seem to have occurred to the author.) Chapter nine does turn to security risk analysis, briefly, but with some helpful pointers for the evaluation process. Risk mitigation, in chapter ten, looks rather tersely at choice of controls, and does an oddly complicated review of cost/benefit analysis. Styles for different types of reports resulting from risk assessment are outlined in chapter eleven. Chapter twelve presents a fairly standard look at project management (with extra emphasis on reporting). Chapter thirteen lists, but does not adequately describe, various risk assessment methodologies. Despite the weaknesses, oddities, and gaps in the book, it does provide a decent overall guide, and some very useful practical suggestions. It is not quite complete in all areas, and therefore likely unsuitable as the sole source of advice on the risk assessment process for the novice, although the newcomer would not go far wrong in following the counsel of this work. The experienced security or risk assessment professional will still find valuable recommendations and advice. For anyone in the security or risk analysis field, the book is well worth considering. copyright Robert M. Slade, 2006 BKSCRAHB.RVW 20060919 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