RISKS-LIST: Risks-Forum Digest Monday 6 January 2003 Volume 22 : Issue 47 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/22.47.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Bruce Schneier: Counterattack and vigilantism (Monty Solomon) Risks of diverse identification documents (Markus Kuhn) Over 160,000 join Massachusetts list to block telemarketers (Monty Solomon) Automakers block crash data-recorder standards (Monty Solomon) Re: O Big Brother, where are thou? (Jerrold Leichter) Re: Caller ID untrustworthy (Danny Burstein, Jerrold Leichter) REVIEW: "Minimizing Enterprise Risk", Corinne Gregory (Rob Slade) REVIEW: "Enterprise Information Security", Peter Gregory (Rob Slade) REVIEW: "Enterprise Security", David Leon Clark (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 6 Jan 2003 08:38:53 -0500 From: Monty Solomon <montyat_private> Subject: Bruce Schneier: Counterattack and vigilantism Excerpt from CRYPTO-GRAM, December 15, 2002 by Bruce Schneier Counterattack This must be an idea whose time has come, because I'm seeing it talked about everywhere. The entertainment industry floated a bill that would give it the ability to break into other people's computers if they are suspected of copyright violation. Several articles have been written on the notion of automated law enforcement, where both governments and private companies use computers to automatically find and target suspected criminals. And finally, Tim Mullen and other security researchers start talking about "strike back," where the victim of a computer assault automatically attacks back at the perpetrator. The common theme here is vigilantism: citizens and companies taking the law into their own hands and going after their assailants. Viscerally, it's an appealing idea. But it's a horrible one, and one that society after society has eschewed. ... http://www.counterpane.com/crypto-gram-0212.html#1 ------------------------------ Date: Sun, 05 Jan 2003 01:09:40 +0000 From: Markus Kuhn <Markus.Kuhnat_private> Subject: Risks of diverse identification documents The Home Office is currently running a consultation exercise on the introduction of an identity infrastructure for Britain. This would consist of a biometric database with basic records of the entire population. Anyone in the database would be able to get an identity card, which would essentially enable the holder to grant easily read access to his or her record to any peer who needs some form of assurance about one's identity. Details on the consultation are on http://www.homeoffice.gov.uk/dob/ecu.htm The system proposed is nothing unusual and quite similar to what most European and many Asian countries have used successfully for several decades. Such identity infrastructures are generally widely accepted in these countries, where most people consider them today to be a desirable and effective protection against what has become known in some countries that still lack them as "identity theft". Nevertheless, there is fierce opposition to the proposals from various British privacy advocacy groups. Similar discussions can be observed at the moment in the US and Japan. While much of the opposition is of a somewhat religious/tinfoil-hat nature and therefore difficult to address, some of it has been voiced by notable computer-security experts and therefore deserves some serious response. The probably most commonly recurring theme is that the introduction of a national identity card would lead to over-reliance on a single document. The need to corrupt only the issuing procedures of a single mechanism -- so the often expressed concern -- would ultimately make identity theft easier rather than harder. This is probably based on the implicit assumption that independent identity systems perform independent checks with statistically independent failure probabilities. Therefore their security should increase exponentially with the number of verification systems and more would be better. Defense-in-depth and its use of multiple diverse security mechanisms is in general a feature of sound security engineering. However, applying this general idea in the context of government infrastructures against identity theft this way is in my opinion horribly wrong and naive for a number of reasons, which I'd like to address very briefly. The most obvious problem is that the UK's present alternative -- identification based on multiple documents and issuing procedures -- adds very little as none of the currently widely available documents is protected by controls of desirable strength. This is just illustrated again by recent media demonstrations on how easily it is to abuse UK birth certificates: http://news.bbc.co.uk/1/hi/programmes/kenyon_confronts/2625395.stm In practice, anyone wishing to verify an identity gets only the *minimal* protection of all the ID schemes in common use, because as soon as you break one of them, you can quite easily proliferate your fake identity into several other systems. Get a fake UK birth certificate (fairly easy) and apply with it for a fake UK drivers license (therefore also not much more difficult), use both to get a fake UK passport and all three to comfortably get fake account access, education degrees, travel documents, security clearances, etc. etc. Most of the existing systems depend on each other, which leads easily to circular verification (A thinks B knows I and B thinks A knows I). They all lack the somewhat more expensive direct checks of non-document evidence that for example a properly protected distributed add-only database of the biometric long-term history of those registered could support economically and effectively. Multiple documents? Unfortunately, the world of fake ID documents currently works more like "Buy one, get three more free!" The number of systems doesn't count much after all. But this is not the only reason why it is so crucial to have at least one identification scheme that is seriously difficult to break, while having more than one of these is unlikely to be worth the cost and hassle. There is first of all also the problem that within a single infrastructure, it is far easier for those in charge of its integrity to verify and ensure that the overall policies such as the separation of duties for critical checks really leads to checks that are independent by design, and not by chance. Another reason is that the costs for the training/equipment/time/etc. necessary for the adequate verification of security documents increases at least linearly with the number of different document types accepted. And the risk of fraudsters finding by brute-force search one accepted type of identification for which a particular verifier is not well prepared to recognize comparatively simple fakes increases even exponentially with the overall number of different identification forms accepted. Hence I am not surprised by the desire in the UK government to finally also offer its tax payers one single simple cheap properly engineered and run identity infrastructure. It is needed to replace all the existing often ridiculously weak alternatives (including old birth certificates, old driving licenses, magstripe-cards, knowing mother's maiden name or showing a laser-printed utility bill) that are all currently used by especially the UK financial industry as acceptable means for gaining access to critical personal information and property. Perhaps the discussion should first of all be driven by comparing actual practical identity-theft versus privacy-violation statistics in countries with and without proper government-provided identification infrastructures, instead of naively applying generic security recipes such as more-mechanisms-are-better to an application area with far more specific properties. Markus Kuhn, Computer Lab, Univ of Cambridge, GB http://www.cl.cam.ac.uk/~mgk25/ ------------------------------ Date: Fri, 3 Jan 2003 19:38:03 -0500 From: Monty Solomon <montyat_private> Subject: Over 160,000 join Massachusetts list to block telemarketers The brand-new Massachusetts anti-telemarketing Do-Not-Call Registry had 20,000 people enroll even before it opened officially on New Year's Day, and then 140,000 more in its first two days of official existence. State officials anticipate that one-third of Massachusetts' 3 million residential customers will sign up in the first month. [Sources: Bruce Mohl, *The Boston Globe*, 3 Jan 2003; and Signup begun to ward off telemarketers, Associated Press, 1 Jan 2003' PGN-ed] http://www.boston.com/dailyglobe2/003/business/Over_140_000_join_list_to_block_telemarketers+.shtml http://www.boston.com/dailyglobe2/001/metro/Signup_begun_to_ward_off_telemarketers+.shtml ------------------------------ Date: Mon, 30 Dec 2002 00:16:03 -0500 From: Monty Solomon <montyat_private> Subject: Automakers block crash data-recorder standards Highway safety could be vastly improved if black boxes that record information about car crashes were standardized, experts say, but they contend that vehement objections from the automobile industry are thwarting efforts to set a standard. About 25 million late-model cars and trucks, most built by General Motors and Ford, carry the boxes, which record crash information including how fast a vehicle was moving, whether the seat belts were buckled and how big a jolt the occupants suffered at impact. ... [Source: Matthew L. Wald, *The New York Times*, 29 Dec 2002; PGN-ed] http://www.nytimes.com/2002/12/29/national/29CRAS.html ------------------------------ Date: Sat, 4 Jan 2003 10:53:08 -0500 (EST) From: Jerrold Leichter <leichterat_private> Subject: Re: O Big Brother, where are thou? (Nilges, RISKS-22.45) spinoza1111at_private (Edward G. Nilges) notes that TIA -- which he doesn't like -- will apparently be based on the commercial Groove software product and notes that those TIA is targeting will thus have access to the same software and can modify what they do to avoid being spotted by it. Preventing this, he claims, is equivalent to the Halting Problem. The politicians, as usual, are ignoring "the facts" because they are inconvenient. Nonsense. The Halting Problem has nothing whatsoever to do with the use of off-the-shelf software, with TIA, or with anything I've seen proposed. I have many doubts about TIA myself, but the last thing we need is pseudo-science -- scientific words used inappropriately to give an imprimatur of "objective, scientific fact" to an unrelated argument. (See the use of "energy" in any ad for crystals or other new-age, hmm, product.) Why does the Halting Problem have nothing to do with this? Does Mr. Nilges seriously believe that Groove, whatever it might do, comes out of the box configured to search for terrorist activity? Let's get real here: Any product of this sort is a framework; you tune it to look for what you think is of interest. Let's apply Mr. Nilges's argument to a simpler setting. I propose to scan mail messages for the use of various terms of interest using my secret, proprietary perg program. You wish to send messages that won't trip my detector. Does it help you in your attack if you find out that perg is actually grep, which you have a copy of? What you need to know is what keywords I'm looking for -- not *how* I'm searching for them. Sure, maybe knowing that I'm using regular expressions will help you in theory, but unless you are willing to use messages of unbounded length, there actually isn't any difference between regular languages and even unrestricted languages. Now, no one would propose using grep, or any such simple-minded search, for this kind of thing today -- whatever jokes Mr. Nilges makes about "hackerz". If we start at the lexical level, the existence, for many years now, of text-to-speech converters with human-level performance means that alternate spellings that have recognizable pronunciations can be readily recognized. But a few minutes with even a program that's way behind the state of the art -- the grammar checker in Word -- shows that programs these days do a reasonable job of recognizing fairly deep syntactic and semantic aspects of natural language. Or try some of the translators out there - they can produce some hilarious results, but look at how often they get the basics right. If what you are looking for is a system that stands a good chance of picking up "suspect" text, and you are willing to accept false positives -- the technology is probably there. Beyond all this, like the silly MIT paper about random vs. targeted searching at airports, Mr. Nilges ignores the fact that, while any search system will probably end up looking at many "incidental" aspects of (say) terrorism (e.g., buying one-way tickets), some are fundamental (if you want to produce a bomb, you need explosives, and while there are a variety of explosives around, but not an unlimited variety), and some are incidental but difficult to change (you *could* receive terrorist training anywhere, but in practice there are only so many places in the world where there are training camps; visiting those areas is a pretty good indicator). And even the "pure incidentals" can be valuable as long as they are secret. There are many legitimate complaints to be made about TIA on social and political grounds. There are also practical issues of implementability, though many have more to do with scaling than anything else -- data mining, difficult as it is to justify on theoretical grounds, seems to work well enough that many businesses are spending -- and saving -- questions to doublecheck. On the other hand, if you call from your work number then the service rep will ask quite a few more questions. Now the key thing here is, as the original poster pointed out, the validity and accuracy of the displayed phone number. And yes, standard "caller id" (more officially known as "calling party number" or CPN) can be spoofed. Or, for that matter, be inaccurate. Or wrong. Sometimes maliciously, sometimes for good reason. A legitimate purpose, for example, would be at a hospital. When a nurse calls out from the fourth floor intensive care unit the CPN might be sent over as the main hospital number. On the other hand, a telemarketer may have other reasons for making you think a call is local... However, when you call a 1-800/888/877/866 (and soon 855) toll-free "area code" [a] number such as in this case, the phone number showing up on the display is NOT the CPN, but rather is courtesy of Automatic Number Identification (ANI). This number is generated and sent across by the telco, NOT by your equipment, and is much, much, harder to falsify. (ANI is used internally by the telcos and the long distance carriers and similarly connected groups for, among other things, billing purposes.) [b] While these two numbers (CPN and ANI) are often the same, and in the case of residential users and small businesses are almost always identical, this is not always the case. But again, the key point for RISKS is that spoofing ANI takes a lot more knowledge, equipment, and access, than commonly available. [a] 800/888/877/866 "area codes" are technically called "service access codes" since they don't have geographic distinctions. In the Old Days the first three digits of the phone number following the 800 did provide destination routing -- for example, 800-225-.... was the Boston area, but that hasn't been the case for a long, long, time. [b] since the company you're calling pays the charge, they have the right to get a full detailed listing of the phone numbers reaching out to them. In the case of AMEX, etc., this is a realtime display on the service rep's screen -- which will also pull up your account info with them. The local tow-truck company, on the other hand, may simply get it as a printout in the monthly bill. ------------------------------ Date: Sat, 4 Jan 2003 09:43:22 -0500 (EST) From: Jerrold Leichter <leichterat_private> Subject: Re: Caller ID untrustworthy (Lodge, RISKS-22.46) [Much of the content of Danny's message (above) was also noted in detail by Jerrold Leichter. In order to avoid duplication, I have omitted part of Jerry's message, but included his last paragraphs, where CLID refers to Calling Line ID, also known as Calling Number ID, and incorrectly as Caller ID. Apologies if I left out something nonduplicative. PGN] By its nature, ANI must be difficult to forge. (Also by its nature, it may not point to a number that would make sense to the average person: It identifies the line that should be billed, which may or may not correspond to a dialable telephone number.) Telephone companies want to be paid, and won't let someone into a position where they can specify ANI unless they are sure they will be good for the charges. PBX users can specify CLID, but ANI is set at "the other end of the link". Does this mean ANI can't be faked? Certainly not, but the massive fraud *against them* that such fakery would allow would certainly drive the Telcos to fight it vigorously. Just to complete the picture: *Receiving* ANI isn't cheap. Commercial-scale 800 services from the major Telcos deliver true ANI. Consumer 800 number services have no way to deliver ANI, since consumers have to direct way to receive it. But there's an intermediate level: Some of the cut-rate 800 providers sell services that deliver what looks like ANI information, but is actually derived from CLID (since that way they don't have to pay to get the ANI from the Telco they connect to). Obviously, you as a customer have no way of knowing if the company you called is fooling itself by buying el cheapo 800 service -- but on the list of things to worry about, that certainly can't be all *that* high. -- Jerry ------------------------------ Date: Mon, 6 Jan 2003 08:09:27 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Minimizing Enterprise Risk", Corinne Gregory BKMIENRI.RVW 20020916 "Minimizing Enterprise Risk", Corinne Gregory, 2003, 0-273-66158-2, UK#156.99/C$319.99 %A Corinne Gregory corinne.gregoryat_private %C London, UK %D 2003 %G 0-273-66158-2 %I Prentice Hall/Financial Times %O UK#156.99/C$319.99 +1-201-236-7139 fax: +1-201-236-7131 %O http://www.amazon.com/exec/obidos/ASIN/0273661582/robsladesinterne %P 120 p. %T "Minimizing Enterprise Risk: A practical guide to risk and continuity" Chapter one defines four types of risks--and immediately contradicts itself with tables of other types of risks. The basic point seems to be that risks exist. Chapter two looks at the new product development process and reputation management (after all, one type of risk is bad publicity). There is a look at risk mitigation, but not risk acceptance or avoidance, a cost/benefit analysis that is not very detailed, and a contrived use of the "9/11" World Trade Center disaster (but no mention of the brokerage firm that survived) that undercuts the ultimate message about having a disaster plan. Enterprise continuity, in chapter three, has, like other chapters, good ideas mixed in with a random collection of topics from business continuity planning, disaster recovery, incident response, contingency planning, and other areas. Business impact analysis is proposed as a justification for planning, in chapter four, although it should be part of risk analysis itself. Otherwise this material is pretty basic; get a committee, list the risks, think of what to do about them; the type of thing you would see in any decent article on risk management. Chapter five states that Internet use is risky, and has a (short) list of some precautions. Anyone who thinks that they understand risk management or business continuity planning from reading this book is seriously misled, and possibly a liability to the company. copyright Robert M. Slade, 2002 BKMIENRI.RVW 20020916 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Fri, 3 Jan 2003 08:09:33 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Enterprise Information Security", Peter Gregory BKENINSE.RVW 20020916 "Enterprise Information Security", Peter Gregory, 2003, 0-273-66157-4, C$19.99/UK#156.99 %A Peter Gregory peter.gregoryat_private %C London, UK %D 2003 %G 0-273-66157-4 %I Prentice Hall/Financial Times %O C$19.99/UK#156.99 +1-201-236-7139 fax: +1-201-236-7131 %O http://www.amazon.com/exec/obidos/ASIN/0273661574/robsladesinterne %P 145 p. %T "Enterprise Information Security: Information security for non-technical decision makers" The executive summary states that this book is intended to present information security to executives. The introduction certainly shows that it isn't intended for technical people, who would ask what the difference was between access over the Internet and remote access, or a network using TCP/IP and the Internet. Chapter one asserts that the events of September 11, 2001 woke executives up to the importance of security. (Yeah, right.) However, there is a good analysis of the reasons that the Code Red/Nimda worm was successful. The definition of a threat, in chapter two, is pretty bad, and the definitions of various types of malicious software are really bad. The section on hacking lists a variety of attacks (heavy on social engineering), the "hacker profiles" concentrate on system exploits, there is a random list of security problems, and then an surprisingly good definition of vulnerability. Authentication and authorization are reasonably handled, but confused with extraneous details in chapter three. Access control is equated with firewalls, and the discussion of cryptography is all right but full of minor errors. (RC 2 and RC 4 have been compromised, Skipjack has been released for limited review, a digital signature does need a key but not necessarily an additional password, the loss of a key is not sufficient to repudiate a digital signature, and the ping-of-death does not compromise integrity.) The material on antivirus protection refers only to scanning, and the material on audit deals only with logs. Chapter four is supposed to be about policies, but actually concentrates on procedures, containing random thoughts and many gaps. People are the weak link in security, we are told in chapter five, and, as with other sections it uses non-standard terms in the discussion. More haphazard thoughts are in chapter six, while chapter seven has a poor definition of privacy and a grab bag of topics. In chapter eight a casual list of topics seem to be indiscriminately assigned to the standard important/urgent quadrant chart. OK, this is not intended for professionals; it is intended for managers. But, even if we give full reign to the usual jokes -- those who can't, do; those who are incapable of mastering anything, go into management -- it's still bad form to deliberately mislead them this way. copyright Robert M. Slade, 2002 BKENINSE.RVW 20020916 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Thu, 2 Jan 2003 08:22:00 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Enterprise Security", David Leon Clark BKESTMDG.RVW 20020916 "Enterprise Security", David Leon Clark, 2003, 0-201-71972-X, U$39.99/C$62.99 %A David Leon Clark %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2003 %G 0-201-71972-X %I Addison-Wesley Publishing Co. %O U$39.99/C$62.99 416-447-5101 fax: 416-443-0948 %O http://www.amazon.com/exec/obidos/ASIN/020171972X/robsladesinterne %P 264 p. %T "Enterprise Security: The Manager's Defense Guide" The preface is heavy on buzzwords (and a few spelling errors) with little attention paid to concepts and structure. Part one would like us to think of the forging of a new economy. Chapter one asks "what is e-business," and, with a little re-interpretation of history (the Internet had been in existence for twenty two years and had five million users, a significant number private and commercial, before it "became available to the public" according to this book) and ignoring of inconvenient facts (the hyperinflation of dot com IPO stocks is stated to prove the success of e-business just before we are told that the dot com failure was inevitable because of stock hyperinflation) tells us that e-business uses the net and makes money. Some security jargon is introduced in chapter two. A confused recycling of trade press myths about blackhats, in chapter three, seems to state that these are the only malicious opponents of e-business: there is no mention of insider attacks. Part two looks at protecting information assets in an open society. Chapter four demonstrates an amazingly consistent failure to understand the technologies supposedly being explained: a De-Militarized Zone (DMZ) is, by definition, not abandoned outside the firewall, and Simple Key Management for IP (SKIP) is not a virtual private network (VPN) product. There are more buzzwords, miscellaneous security concerns, and more mistakes (ActiveX is *not* multi-environment) in chapter five. Part three talks about waging war for control of cyberspace. Chapter six looks at attacks by syntax, and demonstrates more TCP/IP errors. (Packet filtering is not exactly built into IP: the ability to handle a packet based on destination is central to the idea of networking. The ping-of-death has nothing to do with fragmentation offsets since it is a single packet, and it is not too small, but too large.) There is a confusion of attack scripts and script viruses (and cookies, too, for good measure) in chapter seven. Countermeasures and attack prevention, in chapter eight, actually looks (tersely) at incident response. The material isn't too bad, but has very little detail. Having talked about DDoS (Distributed Denial of Service) in chapter six, the attack now gets more pages, but little more detail. Chapter ten is a grab bag of random safeguards and countermeasures, as is eleven. Part four deals with active defense mechanisms and risk management. Chapter twelve, entitled vulnerability management, suggests collecting alerts. Given what we've seen so far, it is strange that chapter thirteen *does* address the nominal subject of risk management, albeit not very well. This confused collection of random concepts adds nothing of value to the security literature. copyright Robert M. Slade, 2002 BKESTMDG.RVW 20020916 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 29 Mar 2002 (LAST-MODIFIED) From: RISKS-requestat_private Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, send e-mail requests to <risks-requestat_private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomoat_private . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address <x@y>" ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risksat_private with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 21" for volume 21] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 22.47 ************************
This archive was generated by hypermail 2b30 : Mon Jan 06 2003 - 20:49:40 PST