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 little bit of filtering is O.K., but more isn't necessarily better," says Vicky Rideout, vice president of the Henry J. Kaiser Family Foundation, which conducted a study showing that when anti-pornography Internet filtering software is set at a low level of restriction, it's just as effective as when it is set a high level, and is far less likely to prevent searchers from reaching bona fide health sites. But some observers, such as Judith F. Krug of the American Library Association, think that filters are such blunt instruments that they should not be used at all in public institutions: "Filters are just fine for parents to use at home. They are not appropriate for institutions that might be the only place where kids can get this information." The filtering programs generally block any references to sex-related terms; examples given by the report include such subjects as safe sex, condoms, abortion, jock itch, gay, and lesbian. [*The New York Times*, 11 Dec 2002; NewsScan Daily, 11 December 2002] http://partners.nytimes.com/2002/12/11/technology/11FILT.html
Freedom of sXYZch bear@sonic.net (Ray Dillinger) (smirk, computers) "Congress shall make no law abridging the freedom of sXYZch, or the right of the people peaceably to XYZemble, and to peXYZion the government for a redress of grievances." — but your ISP might. [This item also noted by Carl Ellison. I changed the three-X strings in Ray's original piece to YXZ, in order to avoid having this issue ex-filtrated. PGN]
A Web site called ebayupdates.com, having no relation to the eBay auction site, was created as part of a scam to obtain credit information fraudulently from eBay customers. The scam was discovered by the private Internet watchdog group SANS Institute Internet Storm Center, and was confirmed by an eBay executive who said: "Some members have reported attempts to gain access to their personal information through e-mail solicitations that are falsely made to appear as having come from eBay. These solicitations will often contain links to Web pages that will request that you sign in and submit information. eBay employees will never ask you for your password." [Reuters/*San Jose Mercury News*, 11 Dec 2002; NewsScan Daily, 11 December 2002 http://www.siliconvalley.com/mld/siliconvalley/4713932.htm
On 6 Dec 2002, Federal agents raided Ptech in Quincy, Massachusetts, reportedly under suspicion of financial links to Osama bin Laden. Ptech provides unclassified software to many U.S. Government agencies and armed services), and thus there suspicions were raised regarding possible Trojan horses installed in their software. However, on 9 Dec 2002, Justice Department officials said that they do not have any reason to believe any federal systems have been compromised. The search was reportedly done "in connection with an on-going financial crime investigation," according to a U.S. Attorney, rather than part of any terrorist investigations. [Sources: (1) Feds Raid Boston Area Computer Firm Suspected of Links to Al Qaeda Brian Ross, 6 Dec 2002, courtesy of Monty Solomon http://www.abcnews.go.com/sections/GMA/DailyNews/terror_raid021206.html (2) Justice states Ptech presents no security risk, Wilson P. Dizard III and Patience Wait, *Post Newsweek Tech Media*, 9 Dec 2002, courtesy of Lillie Coney at ACM; severely-PGN-ed]
A study by Aaron Schatz has found that the top ten search terms used on Lycos Net this year have been: 1, Dragonball (the Japanese cartoon); 2, Kazaa (the music and video file-swapping service); 3, tattoos (that's right -- tattoos); 4, Britney Spears, the pop singer who, oops, did it again; 5, Morpheus (file-swapping); 6, NFL, the National Football League; 7, IRS; 8, Halloween; 9, Christmas; and 10, Pamela Anderson, the actress and, uh, celebrity icon. Schatz says, "No matter how the news ebbs and flows, people still use the Internet for entertainment." So we see. There just doesn't appear to be that big a demand for information on the origins of the First World War. [*USA Today*, 10 Dec 2002; NewsScan Daily, 10 December 2002] http://shorl.com/fovikinustuko
To overcome the natural reticence companies have against exposing the cases in which they have been victimized by digital attacks, Britain's National Hi-Tech Crime Unit (NHTCU) says it will grant full anonymity to businesses, if they are forthcoming. This is of course not a new concept, but is being tried in hopes it will encourage greater cooperation. [Source: zdnet/Reuters, 9 Dec 2002; PGN-ed, courtesy of Keith Rhodes] http://zdnet.com.com/2110-1106-976530.html
In a number of recent presentations, I have been asked about virus "traps" or "tarpits." The references are to the idea of throttling, and I have finally found the actual paper, rather than the news stories about it: http://www.hpl.hp.com/techreports/2002/HPL-2002-172.pdf The idea is simple and (within a limited scope) potentially quite effective. Simply include, in the network stack, programming to limit the number of connections that any computer is making. In particular, limit "new" connections, to machines not normally dealt with. This ensures that normal work, at human generated speeds, proceeds normally, while automated, random connections are restricted. There are a few caveats to make. The paper refers to viruses, and, of course, what throttling would block are not viruses but classic worms, which make direct connections to other machines. In particular, email viruses might be somewhat restricted, but a Melissa or Loveletter situation would likely be slowed only marginally: connections to the regular mail server would not be "new." Throttling will only be effective against "fast burners": it would definitely help in a situation like the Code Red infestation where a third of a million machines were infected within hours. Slower infectors would be less impeded, and a number of viruses and worms restrict their own spread in order to avoid detection. In addition, a number of viruses now work by replacing the network stack, and therefore this protection would be lost, unless additional protections were layered around the stack. (It would also be fairly simple for viruses or worms to simply start carrying their own network stack.) rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
So, in one of my many editorial positions, I sent something out for review to several colleagues. One question I asked was "Is this paper significantly different from the same authors' workshop XYZ paper? If not, then we will not publish it again, as a matter of editorial policy." One of the reviewers returned a review that was negative but insightful. However, it ended with: "I think that the paper published in XYZ Workshop is a core part of this paper, although the authors did add some new excrement results." Well, I think that sums up the rest of the reviews I have seen about the paper, but perhaps a bit more candidly than usual! :-) I asked (politely) if something else had been intended and a transcription error had occurred. I got as a response: "Very Sorry!! It should be "experiment". It's a typo. MS Outlook corrected it as "excrement" when it checks spelling and I didn't pay attention.... Very embarrassing, but it's all Bill Gates' fault." Yet another reason I don't use Outlook..... [Mor(e-)on spelling correctors? PGN]
Once upon a time I was the customer of a local ISP, Internet Access AG,
that had an excellent support line, competent people, and excellent dialup
coverage here in Switzerland. They were bought out by a third-tier
telephone company that needed an ISP arm quickly. Things were undisturbed:
same e-mail address, same people, same location, same quality of service.
Somewhat later the third-tier company was bought out by a second-tier
telephone company, call it Sunrays. I could keep the old address. I was
still a paying customer, although Sunrays also offers free accounts.
Sunrays has a history of obtuseness about the Internet and Internet service
-- for instance they don't seem able to distinguish what should and what
needn't be done through secure web pages, they mix languages carelessly
(pages are available in German, French, Italian and English), and the FAQs
are a bad joke. Long ago I remarked this to a company officer I know
socially, and his response was a shrug and a "not my department".
This didn't matter much to me, though. I use their Internet service only
for mail, directly through a POP3 server.
Late last week they began rejecting my incoming mail, and all that was in
in my POP3 mailbox was this message:
Your mailbox is full! It is currently over its allowed capacity.
But except for that message the mailbox was empty.
Here I discovered that even for paying customers their only Internet
support other than the FAQs is a premium-priced phone line, another example
of not getting it. (I omit a long and familiar kind of tale about how long
it took and what I had to do to get anyone to pay attention to the
problem.)
Here's what had happened.
On 7 August, with no notice to me, they began filtering spam. The filtered
mail is directed to a mail folder named "Spam" which is visible only to
users of the browser interface or MS Outlook. I use neither. Between
August and late last week they had filed enough mail there to occupy my
account's entire storage quota. I was eventually told I had to log on to
the Web interface — my first time using it — where I was able to see the
situation and empty that folder. He tells me they're thinking of sweeping
spam folders automatically when they near being over quota, but that's for
the future.
After clearing out all the spam — there seemed to be no false positives,
which is consistent with how much still gets through — I went to the
"personalization" page, where I checked the box for Sunrays to send me
their Internet-matters newsletter. But the server wouldn't accept that
change unless I also added a whole lot of other information including my
birthdate, telephone number, address, and many other things they have no
need to know, or already have on file. So no change.
Obviously there's a lot wrong here.
It's clearly a RISK to assume that all their customers are using the mail
service through their web interface, where Sunrays may well have posted
something about their technique of filtering spam. As a matter of fact,
they know perfectly well that some customers are using POP3, because one of
their rare useful FAQs is a POP3 how-to for the Eudora mail client.
It's clearly RISKy to send an unclear message when you could perfectly well
send an informative one.
It's RISKy to send such messages only when the damage has already been
done; for instance, they should send (informative) warning messages long
before the user's space is over quota.
And so on. As remarked above, they really don't get it. I'll be shopping
for a better service. And perhaps offering them my own services, since I
can be bought. But I don't expect them to understand any of this.
While on one hand I don't believe that EAL4 is an especially strong statement, particularly given the protection profile being used, I think Jonathan Shapiro's comments miss the mark. Today, EAL4 is the best we're going to see in a large scale commercial product evaluation. The security community barely knows how to do EAL4 in a consistent, cost-effective manner: don't expect to see higher levels except for small-scale things like smart cards. If EAL4 doesn't provide value to the customers of the evaluated products, then our whole notion of evaluation is flawed (and it just might be). Regarding EAL7: >As I mentioned before, EAL levels run from 1 to 7. EAL1 basically means that >the vendor showed up for the meeting. EAL7 means that key parts of the >system have been rigorously verified in a mathematical way. EAL7 isn't the solution, it's just another problem. We're still learning what "key parts" we're supposed to verify, and what it is we might want to prove about them. Windows has huge chunks of behavior that people rely on every day, and only a tiny fraction of those behaviors can be effectively modeled in a mathematical way. Without a rigorous model you can't do that rigorous proof, and we aren't going to give up word processing simply because we can't prove mathematically that "undo" always works correctly. Regarding EAL4: >EAL4 means that the design documents were reviewed using non-challenging >criteria. This is sort of like having an accounting audit where the auditor >checks that all of your paperwork is there and your business practice >standards are appropriate, but never actually checks that any of your >numbers are correct. An EAL4 evaluation is not required to examine the >software at all. While I like the choice of an audit as an analogy, the analogy is wrong. Having lived through various evaluation activities, I can attest to the fact that you DO have to show that your numbers are correct, even at EAL4, and you have to show it in the manner that most third parties are going to respect: you do a lot of requirements-based testing and you have to show that the testing covers all of your security requirements. While it is true that the criteria for the design document review might not be especially strict, at least in comparison to doing formal proofs, that part of the process gets very expensive, especially for US-based evaluations. Why? Because you can't use your off-the-shelf design documents: you have to rewrite them to satisfy the evaluators. This is getting better, but it's still a source of high costs and uncertain schedules. >An EAL4 rating means that you did a lot of paperwork related to the software >process, but says absolutely nothing about the quality of the software >itself. There are no quantifiable measurements made of the software, and >essentially none of the code is inspected. Buying software with an EAL4 >rating is kind of like buying a home without a home inspection, only more >risky. Very wrong. Home inspections are based on external inspections of major components and possibly a few tests like water quality, radon, lead, asbestos, etc. Inspectors rarely disassemble the house to compare the internal structure against the blueprints. And few home inspectors actually try to burn the flameproof drapes, but that's what you'd need to do for EAL4 if your Security Target says your drapes are flameproof. >Security isn't something that a large group can do well. It is something >achieved by small groups of experts. Adding more programmers and more >features makes things worse rather than better. Microsoft has been adding >features demanded by their customers for a very long time. I'd argue that the problem isn't so much the size of the team as it is the discipline applied to managing the architecture. Without a strong security architecture in place, it doesn't matter how many people work on the system -- it'll still be Swiss cheese. >It is possible to do much better. EROS, a research operating system that we >are working on here in the Systems Research Laboratory at Johns Hopkins >University, should eventually achieve an EAL7 evaluation rating, and is >expected to provide total defense against viruses and malicious code. I think such systems will provide a strong basis for special-purpose devices, but I doubt they'll replace desktop systems, which become a lot like one's office: a mishmash of what you need to get through the day and hopefully be productive. If people have EROS on their desktops, it'll stay virus proof right up until they start installing all those virus-enabled e-mail products and word processors they love so much. This is a variant of the "GOVNET" problem - GOVNET was a boondoggle because it focused on ISO layers 4 and below, ignoring the growing problem of virus-laced e-mail and shared Word documents. Rick Smith (smith@smat.us) Oxford International, Scottsdale, AZ [The most fundamental problem with the evaluation process is that the evaluation is done against criteria evaluation profiles that are established by the organization seeking evaluation. The MS EAL4 is rather lame primarily because the evaluation profiles are not very comprehensive. However, as Rebecca Mercuri's thesis shows in her casting of electronic voting systems into the Common Criteria framework, EVEN IF THE EVALUATION CRITERIA ARE VERY ELABORATE, THEY ARE STILL INHERENTLY INCOMPLETE and significant security vulnerabilities can still remain. PGN]
BKVPNABG.RVW 20020928 "VPNs: A Beginner's Guide", John Mairs, 2002, 0-07-219181-3, U$39.99 %A John Mairs %C 300 Water Street, Whitby, Ontario L1N 9B6 %D 2002 %G 0-07-219181-3 %I McGraw-Hill Ryerson/Osborne %O U$39.99 +1-800-565-5758 +1-905-430-5134 fax: 905-430-5020 %P 584 p. %T "VPNs: A Beginner's Guide" Part one deals with networks and security. The material is not bad; in fact, it is very good; but it is, possibly, too much information on topics which are not, really, relevant to virtual private networks (VPNs). On the other hand, anyone who is a rank beginner to networking as well will certainly have a thorough introduction. Chapter one covers layering architecture and the OSI (Open Systems Interconnection) model, and the text on encapsulation is definitely relevant to VPNs. Network architecture, in chapter two, concentrates on topology and the physical layer. There is a detailed reference to the lower layers of the TCP/IP protocol stack in chapter three. Chapter four's explanation of the basics of security is good, absent some material on threats and parts of risk analysis, but the use of non-standard language may be confusing. Threats and attack methods, in chapter five, is weak: the text lists a variety of network protocol exploits, concentrating on spoofing, and doesn't really bring out the concepts. The explanations of intrusion detection systems and firewalls, in chapters six and seven respectively, are good overviews. Part two is supposed to provide the fundamentals of VPNs themselves, but, rather oddly, does a much poorer job on this central idea than on the previous and following content. Chapter eight is on VPN basics, and nine is on VPN architecture. Part three covers VPN protocols. Chapter ten introduces the tunneling protocols of GRE (Generic Routing Encapsulation) and PPTP (Point-to- Point Tunneling Protocol). L2F (Layer 2 Forwarding) and L2TP (Layer 2 Tunneling Protocol), plus a little bit of IPSec, are reviewed in chapter eleven, although it is not always clear what functions are supported. Part four looks at secure communications. The material on cryptography, in chapter twelve, is not very good: polyalphabetic ciphers are *not* examples of transposition, there is some use of non- standard terminology, the text is simplistic in many areas, and the discussion of key management with asymmetric systems is quite weak. There are similarly feeble explanations and minor errors with respect to cryptographic algorithms in chapter thirteen. The discussion of certificates, in chapter fourteen, is more reasonable, although the section on PKI (Public Key Infrastructure) is a bit terse. Chapter fifteen, on authentication, reprises earlier content on identification and authentication (chapter four), PAP (Password Authentication Protocol, chapter ten), CHAP (Challenge Handshake Authentication Protocol, chapter eleven), but adds discussion of RADIUS, TACACS, and Kerberos, at varying levels of detail. Part five delves into the details of IPSec. Chapter sixteen outlines the components of IPSec, although it is somewhat disjointed with repeated returns to the topics of security associations and the different operating modes. Key management, in chapter seventeen, introduces ISAKMP (Internet Security Association and Key Management Protocol) and IKE (Internet Key Exchange), but does not do so in the detail with which other protocols have been discussed, and does not address the weaknesses of the systems. For some reason the details, and some other key management and exchange protocols, are in chapter eighteen (but still limited analysis). Chapter nineteen does have good deliberations on IPSec architecture and implementation. Part six deals with MPLS (Multi-Protocol Label Switching). Chapter twenty talks about quality of service, and related technologies. A few topics associated with traffic engineering are discussed in chapter twenty one. MPLS is proposed as the answer to quality of service and traffic engineering issues in chapter twenty two. Chapter twenty three outlines some of the components of MPLS and finally explains what MPLS has to do with VPNs, although not in much detail. With some caveats about certain sections of the book, I can recommend this both as a reference to a number of VPN technologies, and to some security related issues with TCP/IP. copyright Robert M. Slade, 2002 BKVPNABG.RVW 20020928 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com
BKIPSECS.RVW 20021001 "IPSec: Securing VPNs", Carlton Davis, 2001, 0-07-212757-0, U$49.99/C$79.95/UK#36.99 %A Carlton Davis carlton@cs.mcgill.ca %C 300 Water Street, Whitby, Ontario L1N 9B6 %D 2001 %G 0-07-212757-0 %I McGraw-Hill Ryerson/Osborne %O U$49.99/C$79.95/UK#36.99 800-565-5758 fax: 905-430-5020 %O http://www.amazon.com/exec/obidos/ASIN/0072127570/robsladesinterne %P 404 p. %T "IPSec: Securing VPNs" Chapter one is an overview of TCP/IP. The material is generally good, but does demonstrate a possible weakness of the book: we are provided with way too much information about a number of areas that are not relevant to IPSec. A similar overabundance of detail (and math) describes symmetric cryptography, in chapter two. Oddly, given the level of particulars in other areas, there is no analysis of the weakness of double DES (Data Encryption Standard). Operational specifics of the various AES (Advanced Encryption Standard) candidates are also included. The mathematical basis of asymmetric cryptography, in chapter three, is not explained as well as symmetric is. In dealing with hashes and message authentication codes, chapter four has lots of math and almost no other discussion. Chapter five provides extensive details about X.509 attribute fields, for digital certificates, and also has a bit of material on PGP (Pretty Good Privacy) and key recovery. The fields of LDAP (Lightweight Directory Access Protocol) are outlined in chapter six. Chapter seven finally talks, very briefly, about IPSec architecture, repeating (from chapter one) the specifics of the IP header, and mentioning some of the components of IPSec. Chapters eight, nine, and ten concentrate of the header structure of AH (Authentication Header), ESP (Encapsulating Security Payload), and ISAKMP (Internet Security Association Key Management Protocol) packets, albeit chapter ten also covers a bit of the handshaking process. There is very little discussion of strengths and weaknesses. There are lots of details related to IKE (Internet Key Exchange) in chapter eleven, but surprisingly little information about what it does or how it works. The header structure and options for the compression function, IPComp, are given in chapter twelve. Chapter thirteen is supposed to talk about implementation, but has a fairly generic example of a VPN and some screen shots from a commercial product. Overall, the book contains lots of technical details, but very little in the way of explanation, discussion, or analysis. You would probably learn just as much about IPSec by reading the RFCs themselves. copyright Robert M. Slade, 2002 BKIPSECS.RVW 20021001 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com
Please report problems with the web pages to the maintainer