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…
A computer problem grounded American Airlines and US Airways flights from coast to coast on Sunday morning, causing delays that lasted all day. A computer company official said human error was the likely cause. American had its planes back up after two hours, while US Airways flights resumed after about three. [Source: Associated Press, 2 Aug 2004] http://nytimes.com/2004/08/02/national/02delay.html
At the annual Black Hat convention in Las Vegas last week, Rebecca Mercuri [who will be a Radcliffe Fellow at Harvard in the coming academic year] challenged computer hackers to test whether it is possible to rig an election held using the unauditable paperless electronic voting machines that have been a frequent subject of discussion in RISKS. She suggested the VoteHere software would be a good system to consider. She also urged other voting system companies to make their software available for scrutiny. ``I'm tired of hearing members of the election community say that no problems have occurred with electronic voting systems when every election there's plenty of newspaper reports of `glitches.' '' (Vendors have made such analyses difficult by keeping their software proprietary.) [*San Jose Mercury News*, 30 Jul 2004; PGN-ed] http://www.siliconvalley.com/mld/siliconvalley/9278952.htm
With businesses and individuals flocking to Internet telephony as a cheap alternative to pricey landline phones, hackers are discovering new opportunities for eavesdropping and making mischief. Tapping phones by hacking into servers and hard drives is much easier than conventional wiretapping and analysts say even though very few incidents have been reported to date, it's just a matter of time. "Once you are running an Internet phone network, all those threats you worry about in the data world will be transferred to the voice world," says one security consultant. "Voice over Internet phones are not in the spotlight of hackers yet, but in this voyeuristic world, if someone can listen in on people's conversations and get a thrill, they will." In addition, voice packets offer new opportunities for disguising and distributing malignant code. "You can spoof a packet and insert myself into a communications flow," says a systems engineer for Mirage Networks. "This kind of threat has been around for a while for data, but now it will move into voice. As you see a broader acceptance of voice over Internet, you'll see more spoofs." [*The New York Times*, 2 Aug 2004; NewsScan Daily, 2 Aug 2004] http://www.nytimes.com/2004/08/02/technology/02virus.html
Police authorities in Russia have broken up a hacker ring that extorted money from British bookmakers by flooding online betting sites with false requests for information in "denial-of-service" attacks and then sending e-mail demanding money for stopping the attacks. Investigators said that bookmaker companies were the most convenient prey because the attacks could be timed to major sport events. The ring consisted of well-educated people in their early 20s who had found each other on the Internet and agreed to work together in the extortion. A Russian police official said: "There was no chief organizer in plain terms, each of them did his bit of work. And they didn't consider themselves criminals." [AP 29 Jul 2004; NewsScan Daily, 29 Jul 2004] http://apnews.excite.com/article/20040728/D843R7EG1.html
Once again (in RISKS-23.46), we have examples of what I call the, "Mr Micawber Syndrome". This syndrome was exhibited very strongly in the stories about the problems of the *Chicago Tribune* and the DC Metro, and also to a certain extent in those about the tethered balloon operator in Baltimore, NASA, Microsoft, and the operators, regulators and promoters of electronic voting systems. For the "bibliophilically-challenged", Charles Dickens' Mr Micawber was a man living on the bread-line for whom, always, "Something will turn up." It appears that this mantra has become the de facto standard when things go wrong with technology today. My experience suggests that this very phrase (or one conceptually synonymous) is often contemporary with the "incident" becoming a "disaster" and, indeed, is probably the trigger for that disaster though its reinforcement of a belief-system. However, the belief that the causation will be resolved in some short, and often very tightly stated, time-frame is seldom, if ever, factored into risk calculations, either beforehand or at the time. I have lost count of the number of times I have seen this behaviour — and readers of these pages will have many more stories of a similar ilk. The RISKS stem from: (1) not considering every "incident" as a potential "disaster"; (2) not pre-establishing a definite time following the recognition of an incident at which its severity will be escalated to that of a "disaster"; (3) not having a Regression Plan that has been tested and can be trusted; (4) not having a pre-set time at which the "Disaster Recovery" or "Business Continuity" plan is put into operation — regardless of what else is happening; (5) not having senior managers who have been properly informed of the RISKS (both of doing something and of doing nothing); (6) having a belief in one's own abilities and those of one's suppliers that transcends the reality of past experience; (7) continually demonstrating an inability to learn from one's and others' mistakes; and (8) too boldly going where everyone has gone before ... and met the same fate! Michael (Streaky) Bacon, Principal, Synigystic Ltd.
http://www.cyberguard.com/news_room/news_newsletter_040628security.cfm Implementing Information Security: Risks vs. Cost Gideon T. Rasmussen - CISSP, CISM, CFSO, SCSA As a security professional who understands how the business world works, I wrote this article to convey the imperative need for security professionals and senior management to see eye-to-eye. Being motivated by business, senior management focuses on productivity and the bottom line. It is sometimes difficult to calculate a return on investment for security, but the damage caused by the absence of efficient controls is far greater than the cost of implementing them. Over the past few years, there have been several highly publicized security incidents ranging from fraud to terrorism. These events demonstrated the need for disaster recovery plans and checks and balances within accounting systems. Many threats present themselves internally in the form of disgruntled or dishonest employees or as the result of social engineering. Human error and neglect are also examples of internal threats. New threats emerge daily. For more information, refer to the CSI/FBI Computer Crime and Security Survey (http://www.gocsi.com/forms/fbi/pdf.jhtml). The U.S. is beginning to mandate information security based on the concepts of due diligence and the prudent man principle. The most recent examples are the Sarbanes-Oxley Act (SOX), the Gramm-Leach-Bliley Act (GLBA) and the Health Insurance Portability and Accountability Act (HIPAA). Compliance with government regulations represents a threat of a sort. Under SOX, senior management is responsible for the accuracy of financial statements. Criminal penalties include fines of $1-5 million and prison terms of 10-20 years. A popular international standard is the Code of Practice for Information Security Management (ISO 17799). A variety of control frameworks have been developed to meet financial and IT security concerns. Two of the leading standards are the Internal Control - Integrated Framework - Committee of Sponsoring Organizations of the Treadway Commission (COSO) and Control Objectives for Information and related Technology (CobiT). IT governance and compliance must be addressed with a formal information security program. Basic elements include security policies, an annual audit and internal controls to mitigate threats and vulnerabilities. Nothing can take the place of an information security audit (http://www.sans.org/score/ISO_17799checklist.php). It is critical to take a snapshot of each site's security posture and work against the findings. Senior management should be aware of the state of the information security program. Usually this is facilitated through an annual security audit report and monthly security status reports. In the absence of current information, it is a good exercise to ask the following questions of information security management: * Are employees required to sign off on the general security policy and specific policies in their functional area as well? * How have applicable security standards been met (e.g. SOX, GLBA and HIPAA)? * Which control frameworks are in use (e.g. COSO, CobiT and/or ISO 17799)? * How are logical and physical perimeters defined? Please provide rationale and diagrams. * Is security built into custom applications from the design phase? * Are all systems routinely patched and hardened? * Are strictly controlled development environments in place (e.g., development, quality & user acceptance)? * What is the maturity level of business continuity and disaster recovery planning? * Are accesses systematically rescinded when an employee leaves or their role changes? * In general, are internal controls layered (i.e., defense-in-depth measures)? * How are the concepts of least privilege and separation of duties addressed? * Is a tactical incident response program in place? * What are the details of the security awareness program? (http://www.cyberguard.com/news_room/news_newsletter_030926threatwithin.cfm) * How recently have each of these topics been addressed? Are they truly maintained? Establishing a culture of security is critical. Information security managers must be well versed in the breadth of the IT career field and other disciplines as well (e.g. physical security, accounting and human resources management). In addition, a security manager must be a passionate advocate and an effective communicator. Interpersonal skills should include the ability to communicate in non-technical terms. Many small organizations lack a dedicated information security professional. This practice should be avoided. As you can see, an effective security program requires constant care and feeding. A dedicated information security professional will reduce the high cost associated with unmanaged risk. Consider the impact on an organization if it does not adequately mitigate risks. In the end, how an organization approaches security depends on its appetite for risk. A healthy dose of paranoia is warranted here. After all, the stakes are extremely high.
Dirk Fieldhouse (RISKS-23.46) asks whether it has ever been confirmed that a cosmic ray has caused a terrestrial computer malfunction. I looked at the issue of what are called Single Event Effects (SEEs) in 2000-2001. Basically, cosmic rays are particles, gamma rays (which are also particles — everything is a particle) and so on which come from outside the earth's atmosphere (primary) or which are generated from primary rays by atmospheric reactions (secondary). Cosmic radiation also keeps us alive - thanks to all those photons which make it through from the sun. Cosmic rays can cause bits to flip, latch up, or burn out in computer memories. As far as I could tell, no one had recorded a processor fault due to radiation by 2001. The problems were first noticed with the advent of SRAMS in 1978 when the bits got small enough to be affected by alpha particles (helium nuclei) of around 5-10 MeV (Mega-electron-Volts. Mass and energy are identical, measured in electron-Volts). Alpha particles with these energies can produce up to 3 million electron-hole pairs in silicon, and 1978 was apparently when SRAMs became sensitive to noise bursts of about that size. These alpha particles were caused by the decay of thorium, a trace element in the silicon substrate. Refine it out, and the noise bursts disappear. Alpha particles of these energies could also come from uranium decay. Classic references are Ziegler and Lanford, Science 206(16):776-88, 16 November 1979, and Journal of Applied Physics 52(6): 4305-12, June 1981. These so-called Single Event Effects (SEEs) in computer memory are a whole branch of avionics research. Satellites and other spacecraft have to worry significantly about them and their processors and memories are designed to tolerate faults so caused. SEEs have been observed and measured in aircraft avionics. Current estimates of the rate of SEEs in aviation at 30-50,000 ft altitude are around O(10^(-9)) to O(10^(-8)) per bit per hour. That is a single bit per 1M of memory per one hundred to one thousand hours exposure. Radiation intensity of the same energy levels on the ground are some two orders of magnitude lower. See Eugene Normand, Single Event Effects in Avionics, IEEE Transactions on Nuclear Science 43, 1996, also available from the Boeing Radiation Lab WWW site. So we are talking O(10^(-11)) to O(10^(-10)) events per bit per hour, which is a rate of one bit per Gigabyte (1 Byte = O(10) bits) per hour to ten hours. Of course, it is theoretically possible that a hugely energetic particle could come blasting through your memory and take out multiple bits. All sorts of things are theoretically possible, but the question is whether people have ever seen them occurring. There was some worry in the 1990's about SEEs in power MOSFETs (semiconductors that operate at thousands of volts, such as used in engine control for electric railway locomotives). Now, it is extremely difficult to determine what the causes of these SEEs are. The SEE-and-avionics people seem convinced that the effects at altitude are primarily due to neutrons. My particle physicist colleagues at Bielefeld were somewhat sceptical. So I researched the literature and found only some very indirect and questionable evidence for this oft-repeated claim. I am inclined to be sceptical also. But this is an aside. That SEEs occur is clear, as is the phenomenon that they are single-bit problems. So how does one know that a particular SEE is caused by a cosmic ray? Basically, one doesn't. It took until 1992 for people to find what they believed to be incontrovertible evidence of an SEE in a spacecraft caused by a cosmic-ray proton, for example. It was a publishable discovery. Fieldhouse finds "... the possibility of a cosmic ray causing a computer malfunction [to be] an obvious threat for space-borne systems". My impression is that it isn't so much of a threat because people spend a lot of time on SEE-tolerant architectures for spacecraft. You don't want to spend large amounts of money launching a spacecraft only to get bits predictably fried and lose data. So you use standard bit-error correction coding techniques implemented in silicon, and put up with the extra resource consumption of all those extra bits. These are not mass-production chips, after all. I find many reasons to question a claim that a cosmic ray trashed the results of a computer vote-counting program. First, I find it implausible that anyone knows that flipping or latching one bit caused a miscount of 4,100 votes. I doubt whether anyone analysed the program or the hardware architecture thoroughly enough to determine that. Show me the chip and the latched bit. And show me the causal chain between that flipped bit and the 4,100 miscounted votes. Anything other than an SEE is a purely theoretical possibility that one can ignore. Second, I presume no one has determined whether the SEE in question was caused by a cosmic ray or by a noise burst in the silicon, or by a thermal problem in the computer, or by the results of a manufacturing error. We have had memory and processors go wrong on us, and nobody ever knows the reasons why. The chip or board just gets swapped and life continues. You need large numbers of SEE events to trace their cause, and you need large numbers of particles to correlate with the large numbers of SEE events and a not insignificant number of competent particle physicists and nuclear engineers to analyse the evidence to conclude that it was a radiation event. I wouldn't call it an urban legend, for that means a tall tale that did not come to pass, and terrestrial SEEs caused by cosmic rays can come to pass. But I would suspect that someone is shooting their mouth off on evidence that is so meagre as not to come close to supporting any assertion of this type. I would question any results generated by a program which is claimed to be sensitive to one SEE. Whoever determined that a cosmic ray might have caused the problem should also have concluded that the program was so obviously untrustworthy that none of its results should ever be believed. Peter B. Ladkin, University of Bielefeld, Germany http://www.rvs.uni-bielefeld.de
To summarise the responses to this item, I have now been able to confirm the story [4100 votes given to candidate in local Brussels election by computer error due to cosmic ray]. It was of course actually 4096 = 2^12 votes, as correspondent Robson and I expected. Correspondents Coggins, Leavitt and Ladkin (see also his RISKS post 'Cosmic Rays and Computers') confirmed that, as expected, such a malfunction could be experienced by a terrestrial computer. The primary known effect is on RAM and the likelihood of a 'soft error' increases with the amount of RAM and the density of components on the chip. Even PCs nowadays, having 1Gb or more RAM, could be noticeably (say, weekly) affected if ECC memory is not used -- unless they are located in tunnels! Presumably this would only be noticed if users expected the running software itself to be stable. Correspondent Cole recalled a mini-supercomputer system in the mid-80s that had frequent parity errors in the instruction cache because "the memory manufacturer had omitted a mask in the memory chip packaging that protected the memory circuits from low-level radiation due to radioactive heavy-metal elements in the ceramic outer packaging layer". Correspondent Baeck (special thanks) provided the election's exact location, Schaerbeek, in his post to RISKS, and that led me to http://wiki.ael.be/index.php/ElectronicVotingRandomSpontaneousBitInversion and finally to http://www.poureva.be/article.php3?id_article=32 (en Francais) The event occurred in the election held on 18 May 2003. An expert review determined that as no software defects had been found on inspecting the source code and no test had been able to reproduce the error, it was probably attributable to a spontaneous inversion of a bit in the RAM of the PC (no explicit mention of cosmic rays). However the report concluded that even if the voting system under review was not perfect the totality of controls was sufficient to be confident in the overall result. I wonder. To a colleague's fundamental question — how was it known that the result was wrong — the answer is that the count was not consistent with the proportional representation rules in the election. So it looks like I'll have to carry on testing my software. Thanks to all. Dirk Fieldhouse, London, UK
An English-language Google search may have failed to confirm the story of a cosmic ray being blamed for a 4096-vote error in Schaerbeek during the 2003-05-18 Belgian parliament election, but a French-language search was more successful, and led me to the following very informative link: http://www.poureva.be/article.php3?id_article=36 from which one learns that the investigation, having failed to find a software bug, and considering the internal structure of the program, concluded that the error was "very likely" due to a spontaneous, random bit flip---for which cosmic rays are a possible cause. They provide a link to http://www.research.ibm.com/journal/rd/401/tocpdf.html on "Terrestrial cosmic rays and soft errors" (in English). The problem, as I (and others) see it, is not that cosmic rays are blamed (that may be correct) but that insufficient safeguards appear to be in place to reliably detect such errors. (Cheap hardware without ECC memory? No other checksums to protect the integrity of the data?) From that same web page, translation mine: "The experts' report underlines that the problem is known, that solutions do exist, but that nothing has been done to protect oneself or to detect, other than by chance or from the absurdity of the results, that such a phenomenon has taken place."
BKOIGTCE.RVW 20040618 "Official (ISC)^2 Guide to the CISSP Exam", Susan Hansche/John Berti/Chris Hare, 2004, 0-8493-1707-X, U$69.95/C$101.50 %A Susan Hansche susan.hansche@pec.com %A John Berti jberti@deloitte.ca %A Chris Hare chare@chris-hare.com, chare@nortelnetworks.com %C 920 Mercer Street, Windsor, ON N9A 7C2 %D 2004 %G 0-8493-1707-X %I Auerbach Publications %O U$69.95/C$101.50 800-950-1216 orders@crcpress.com %O http://www.amazon.com/exec/obidos/ASIN/084931707X/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/084931707X/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/084931707X/robsladesin03-20 %P 910 p. + CD-ROM %T "Official (ISC)^2 Guide to the CISSP Exam" Once again I have to state a bias in regard to this book. I've known about this book since its inception, I've known and advised the authors, I provided bits of the material, and even contributed one appendix. (The annotated bibliography and references--surprise, surprise.) I was asked to review the chapters while the book was in production. The reason was, of course, that I had reviewed all the other CISSP (Certified Information Systems Security Professional) guides. Specifically, the intent was to ensure that this manual, prepared and supported by (ISC)^2 (International Information Systems Security Certification Consortium) was "head and shoulders" above all the other published works. This volume is not perfect, by any means, but it is the best of the current bunch. Taking material from one source is copying, taking material from two sources is plagiarism, and taking material from many sources is research. This volume has not only research but direct input from a great many sources. Some are mentioned in the acknowledgements, a number of others are to be found on the title page, since sections of major articles from the venerable "Information Security Management Handbook" (cf. BKINSCMH.RVW) were included or used as the basis for parts of the guide. Even this doesn't exhaust the contributions, since much of the work is informed by the material in the (ISC)^2 CBK (Common Body of Knowledge) Review Seminar, and over a hundred individuals have had the chance to augment that content. The result is a breadth and currency of information that exceeds any other guide on the market. Sample questions and exams are eagerly sought by candidates for the CISSP exam. This guide has a significant advantage in this regard: not only do a number of the contributors produce questions for the exam itself (therefore being more than passingly familiar with the style and level of difficulty required), but the CISSP exam committee was also approached for advice and input. No source is able to provide "actual" CISSP exam questions, but the examples provided in this volume are very close in form, mix, degree of difficulty, and concept. The book is not without its faults. The sheer volume of the contributors ensured that topics were covered multiple times, and not all duplicated areas have been amalgamated. In addition, the variety of writing styles can make the text disjointed in places, as it moves from section to section and subject to subject. These factors can make the work difficult and demanding to read and follow. The CISSP exam, as the security field itself, is a changing target, and no book can expect to provide the "best" coverage of the topic indefinitely. As well, security is an immense discipline, and touches on an inordinate number of other areas. This work, however, has come closest to spanning the range of subject matter necessary to challenge the CISSP exam, and is currently the best of the guides. copyright Robert M. Slade, 2004 BKOIGTCE.RVW 20040618 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@sun.soci.niu.edu http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer