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…
The following is one item from the regular news digest produced by the students of Charles University, Prague:- CAROLINA No 429, 24 Aug 2001 FROM THE EVENTS OF THE PAST TWO WEEKS (August 9 - August 22) Temelin up Again, down Again The Temelin nuclear power plant was activated again 12 Aug 2001 after three months of repairs to a vibrating turbine (see Carolina 428). The relaunch of Temelin provoked hostile reactions from some Austrian politicians and anti-nuclear and environment activists. News leaked 15 Aug about new vibrations in the turbine, which caused an 18-hour shutdown. However, plant officials claimed the shutdown was used to "balance a rotary part in the turbine." The reactor 19 Aug was automatically switched off due to a software error in a steam-delivery regulator. Temelin opponents claimed this shutdown was the 23rd since the beginning of operating tests. According to Temelin management, the shutdowns are a normal part of the testing procedure and are not related to nuclear safety problems. Temelin CEO Frantisek Hezoucky said Temelin is exceptional only in one respect: it is the very first nuclear power plant where its testing is broadcast live to the public. STUDENTS' E-MAIL NEWS FROM THE CZECH REPUBLIC Charles University in Prague, Faculty of Social Sciences Smetanovo nabr. 6, 110 01 Prague 1, Czech Republic e-mail: CAROLINA@mbox.fsv.cuni.cz ISSN 121-5040 tel: (+4202) 22112252, fax: (+4202) 22112219
Some legal scholars are suggesting that a Web site vandalized by hacker attacks may itself be legally liable if its customers suffer damages and if the site was negligent in maintaining security. Law professor Margaret Jane Radin of Stanford University predicts: "A court is going to say it is negligent of you not to implement preventative measures if they are reasonably effective and affordable." No reported court decisions have dealt with the issue, but Radin says that lawsuits in the near future are highly likely to be lodged against companies and network providers targeted by "denial of service" attacks. [*The New York Times*, 24 Aug 2001; NewsScan Daily, 27 August 2001 http://partners.nytimes.com/2001/08/24/technology/24CYBERLAW.html]
*The New York Times* e-mail version contained an ad offering to teach you a language while you are driving. Imaging trying to learn an irregular verb while negotiating difficult traffic. [You might drive right through a subjunction. Incidentally, someone was jogging toward me this morning when his cell phone rang. At least he had the good sense to stop running. PGN]
The BBC reports that "confidential files containing the identities of alleged paedophiles and their victims were found on a second-hand computer bought from Bristol University". Full story at http://news.bbc.co.uk/hi/english/uk/newsid_1519000/1519889.stm Not a new RISK, but the first time I've seen this particular combination. Does *your* local social welfare department, public hospital, or police station have a statutory duty (in the interest of the taxpayers) to sell, rather than destroy, old equipment ? And if so, is there a mandatory procedure for securely erasing the hard disk first ? Nick Brown, Strasbourg, France.
An anonymous programmer has found a way to decrypt Microsoft Reader e-books on Windows PCs, but has not released it. [Source: Breaking Microsoft's e-Book Code, By Wade Roush, Technology Review, 30 Aug 2001, http://www.technologyreview.com/web/roush/roush083001.asp; PGN-ed; Dave has been predicting this, but then all lame protection seems to be easily broken, relying on the DMCA for protection. Dave's archives are at http://www.interesting-people.org/ . PGN]
I received reports from an AOL user of e-mail's not getting through. Checking log files show that AOL's mail server had received all the messages correctly. Queries to AOL's postmaster account received no response. Web pages run by AOL users suggest the cause of this is that I may have triggered a "suspicious relaying" trap with the AOL server. Assuming this is the case it is interesting that AOL choose to drop the mail silently, when all the information required to make such a decision is available to the mail transport agent before the body of the mail is sent. Thus AOL could choose to refuse the mail politely, using less bandwidth, and informing the sender of a problem, but prefer to waste bandwidth and delete the e-mail silently. The Risk? Assuming AOL cares enough about their subscribers e-mail not to delete it without notifying sender or recipient, or answer questions on the topic. The only way I can see to mitigate the risk is to switch to another ISP. +44(0)1395 232769 Moderated discussion of teleworking at news:uk.business.telework
Normally eBay will not disclose the email addresses of its users. When you wish to send email to an eBay user, eBay provides a proxy service accepting the email and then forwarding it to the recipient. However, if the mailhost for the recipient is down or unavailable, the sender will get a warning email saying that the original message could not be delivered but the system will go on trying, WITH THE E-MAIL ADDRESS OF THE RECIPIENT. Another example of not thinking things through. Vassilis Prevelakis, Distributed Systems Laboratory, Univ. of Pennsylvania Philadelphia, PA 19104-6389 +1 215 898 0375 vassilip@dsl.cis.upenn.edu
But you are forgetting the law of Dual Criminality. A person can only be extradited from one country to another if what the person did was recognised as a criminal offence in the country where they did it. Since pointing out a security vulnerability is not a criminal offence in most countries, extradition can be refused. (Otherwise anyone who drinks alcohol could be extradited to any muslim country and executed!) Of course, the USA could act illegally (as it has done on many occasions in the past). That would technically be an act of war ..... A J Stiles <ajs2@adyx.co.uk> http://pages.zoom.co.uk/~nineladies/
I've just registered with the BT Cellnet site in order to be able to view my mobile phone bill online. I had to choose some authentication items, and I quote here from the website: ====================================================== For security purposes our on-line services are password protected — in order to use them you need to register by providing a username, password, a memorable item, and a password hint. Your Username and Password must be unique to yourself. Try to use something memorable - you will need to use these every time you logon. Your Password will expire every 90 days and you will be required to choose a new one. You will be automatically prompted to change your password whenever you logon after the 90 day period has expired. To make your password easier to remember you can use the same password but add a different number each time a change is needed. For example password1, password2, password3 and so on. ====================================================== Looks like a well-known risk is not as widely-known as we might hope. But wait — it now leaves the realm of "bad", and enters the "mad": ====================================================== The Password Hint is a word or phrase that you can choose to remind you of your password should you forget it. For example if your password is your pet's name then the password hint could be 'pet's name'. The Memorable Item is something that you will need to supply whenever you need to see your Password Hint. Again try use something that is linked to, and therefore will remind you of, your password and password hint. ====================================================== The usual way that Web sites provide for forgotten passwords is to set up a challenge-response, where the user gives a question that should be asked if they forget their password, and the answer they will give to prove who they are. So you can pick things which you are (fairly) sure wouldn't be known by a miscreant, such as "what's the serial number on the back of your watch?" or "what was the name of your first girl/boyfriend?". This has always seemed to me to be a secure enough system where you don't fear network snooping etc. But how am I expected to remember "something that is linked to, and therefore will remind you of, your password and password hint" in order to help me when I've forgotten my password? I know - maybe I'll write it down...... Mike Perry, IBM UK Webserver Group
I recently attempted to apply online for a position with Tarrant County College in Fort Worth, Texas. The first screen in the Web form was for Affirmative Action purposes and required such items as full name, address and Social Security number. Fortunately, I noticed there was no indication the connection had been secured: no warning from my browser and no "locked" icon in the browser window. I quit the site and e-mailed the school's HR department to report the problem and ask for a "snail mail" address to which to send my resume. Later that day I received a response from an HR employee stating the school accepts applications _only_ via the online forms, but they are indeed secure. Alternatively, I was welcome to visit the school's library to apply online using one of their machines if I still felt uncomfortable in doing so over the Internet. I again e-mailed, restating the problem with their supposedly secure connection, and noting that since I lived more than a hundred miles away I wasn't likely to visit the campus simply to fill out a form. Two days later I received a reply stating a "supervisor" would contact me shortly. That was five days ago. No supervisor yet. The risks of such a Web connection that may or may not be secure are obvious. But the hidden - and greater - risk here lies in the institution's apparent blind slavery to this new technology. While no doubt making their jobs easier, the policy of only accepting applications online closes off employment opportunities to an untold number of people simply because they may not have access to the Internet or live within bus, car or walking distance of the campus. Not such an Equal Opportunity Employer, after all, though I know that wasn't their intent. Bill Lamb blam@wmlc.net www.wmlc.net
By this reasoning, one shouldn't buy software from companies that write software in languages that don't make buffer-length checking the norm such as C and it's variants including C++. Languages such as Java, C# and PL/1 don't suffer this unless programmers get too clever and try to squeeze out that extra nanosecond that an indirection may entail. Remember that a computron saved means hours wasted! [Yes, I know this is a more complicated topic, but a vow of poverty isn't the answer to all problems — not that I like being put in the position of defending Microsoft.]
I recently tried to pay for some clothing with a personal check at a large, national clothing store. I was asked for a driver's license, which I produced, and the sale went through normally. I then went to a different department, and, again, tried to pay for more clothing with a check. Produced my license. The clerk told me the "transaction had been declined". I asked why, and she handed me a cash register receipt with a code number and an 800 number. I asked her if I could use her phone to call the number (hoping to straighten out whatever the problem was) and was told they could not use it to call outside numbers. When I got home, I called the number. It was a third party check approval service. The person on the other end of the line asked for my ID (license) number. She then told me that the transaction had been declined because of "unusual check-writing activity". I asked her exactly what that meant. She told me that they had just approved my check number 202 and then tried to use check number 221. The first clerk had transposed two digits while manually entering the check number. So, my second check was declined. Of course, this "wasn't their fault", and "wasn't the first clerk's fault, either...people make mistakes". My comment that this mistake could easily have been cleared up if I had been allowed to know why the check had been declined fell on deaf and uncaring ears. I liked it better when the manager was called and scribbled his initials on the check. Peter Simpson
I had a reservation (via phone) with the Hyatt for a trade show. Later I cancelled the credit card used to reserve it, so I called the Hyatt to give them a new card number. Problem 1: I couldn't find the confirmation number they'd given me. Problem 2: They couldn't find a reservation for me, and insisted I did not have one. And the hotel was booked for the entire trade show. Solution (mine): Booked at another hotel. ... time passes ... I get a statement from the _cancelled_ credit card, listing a charge by the Hyatt for 1 day's stay. Oh oh. I call the Hyatt. The clerk is easily able to call up my record using the credit card number and verify that yes, I had a reservation and yes, I hadn't called to cancel it so I had to pay for 1 night. Oh, and they'd mistyped my name. Which to me explained why they'd 'lost' my reservation in the first place. He got manager approval to refund the credit charge because it lacked a "Cancellation Number", and it'll be at least one billing cycle before it goes through. So they couldn't find my information when I wanted to stay, but could find it to bill. Risks? Reservation clerks not believing customer, inconsistent procedures and lookups, inaccurate data entry still being accepted by credit card company, cancelled card not rejecting charges, probably others. Sandy Antunes <aantunes@science.gmu.edu>
In Risks-21.57, Mike Tuffs writes about his credit-card company getting his phone number despite his having Caller ID blocked. Once again, there are two distinct and COMPLETELY SEPARATE systems that deliver calling phone numbers information to recipients. The system used for toll-free numbers (which the author undoubtedly used to call his credit card company) as well as for long-distance call billing and for 911 services is called ANI. ANI CANNOT be blocked, at least not without making a significant (and likely questionably legal) effort to thwart the telephone system. I suspect the answer about ignoring the "ignore" bit is just a script they give the customer service people, or the agent was just making it up. The bottom line is that your calling number is delivered to the recipient of any toll-free call you make, whether in real time or via a billing statement, REGARDLESS of whether you have Caller ID blocked or not. William Kucharski <kucharsk@mac.com> [Noted by quite a few readers, including the following. TNX. PGN]
[...] An interesting story, and possibly an urban legend, about ANI. When computerized call centers were becoming the norm, a major credit-card company decided to use ANI to help the operators handle customer calls in a more friendly manner. When a customer called from their home number, the computers would automatically match the number to the account holders name, even before the operator had picked up the call. The operator would then, upon hearing the callers voice, respond with <Mr., Ms.> Account Name, how can I help you? Callers were so disturbed by the fact that the operator knew who they were before they had identified themselves that the credit-card company eventually told the operators to stop using this technique. They still know who you are (or are likely to be), but withhold the info and allow you to provide it before they use it. Customers are much happier with this method. When you call an 800 number and reach a call center, your file has likely already appeared on the agent's computer screen, whether they let you know that or not.
BKINSCMH.RVW 20010609 "Information Security Management Handbook", Harold F. Tipton/Micki Krause, 2000, 0-8493-9829-0/0-8493-0800-3, U$155.00 %E Harold F. Tipton haltip@ix.netcom.com %E Micki Krause Micki.Krause@isc2.org %C 2000 Corporate Blvd. NW, Boca Raton, FL 33431 %D 2000 %G 0-8493-9829-0, 0-8493-0800-3 %I Auerbach Publications %O U$155.00 800-272-7737 auerbach@wgl.com slinton@crcpress.com %O available separately 0-8493-9829-0 $95.00 0-8493-0800-3 $59.95 %P 2 vol., 711 p. + 626 p. %T "Information Security Management Handbook, Fourth Edition" As an overview for the CISSP (Certified Information System Security Professional) CBK (Common Body of Knowledge), this work covers a vast range of topics. The CBK, and the book, is divided into ten domains, covering access control systems, telecommunications, security management, systems development, cryptography, security architecture, operations security, business continuity, law and ethics, and physical security. The text provides some excellent articles, some of which are general but detailed overviews, and others that address particular problems or new technologies. However, even with fifty nine articles and over thirteen hundred pages there are gaps, some surprisingly basic. The quality of the articles can vary widely. The first essay, on biometrics, provides an admirable review of the subject, as well as some solid, practical, and useful detail information. The next paper is a rather odd treatment of single sign-on, addressing the concepts well, but in a disjointed manner that makes reading or studying difficult. Following those comes a paper ostensibly dealing with securing connections to external networks. It collates some generic and vague descriptions of a variety of topics, none of which are particularly informative or reliable. (A two-page section on computer viruses contains numerous glaring and significant errors. Personally, I continue to find it appalling that general security texts deal so poorly with this topic.) Other areas covered are firewalls (terse), perimeter security for the Internet (again, but this time with excellent technical information on TCP/IP specifics), extranets (doctrinaire), firewall management (very useful for planning), the OSI (Open Systems Interconnections) network layer security model (questionable utility), the OSI transport layer security model (not much better), application layer security (interesting but undetailed), communications and security protocols (broad overview, concise but fills in some common gaps), security awareness training (reasonable points for success), security architecture (brief but basic), IPsec (good overview), risk analysis (thorough but perhaps a trifle pedantic), trade secret protection (an interesting twist), information security for healthcare (a tad verbose and US-centric), security for object-oriented databases (listing proposals), fundamentals of cryptography (very clear explanations of the math involved), key management (great review of principles, and amusing anecdotes from history of the *wrong* ways to manage keys), Kerberos (extensive coverage of both details and concepts), PKI (Public Key Infrastructure, a quick guide to the basics), microcomputer and LAN security (good concepts, overly optimistic, oddities in details), trapping intruders (quick concepts), Java security (quick basics), business continuity planning (a new process), restoration after disaster (general review), computer crime investigation (good coverage of many aspects), Internet ethics (emphasis on privacy), jurisdictional issues (miscellaneous), intrusion detection (concepts and evaluation points), single sign-on (opinion this time), authentication services (concepts and amusing overview), email security (concept review), ATM (Asynchronous Transfer Mode) security (without really discussing security), remote access (background fundamentals), sniffers (concepts and details), enclaves (firewalls within), IPsec (good details), penetration testing (very basic policies), policy (some good points but quite random), the security business case (opinion), PeopleSoft security (as for any major database), World Wide Web application security (reiteration of general security planning with a few Web specifics), common system design flaws (an important set), data warehouses (standard system development advice with limited security relevance), PKI (simplistic), introduction to encryption (a good one), new models for cryptography application (useful for planning), cryptanalysis (decent review of terminology), message authentication (detailed), UNIX security (concepts and tools), hacker tools (not very detailed), malicious code (theoretical and incomplete), business impact assessment (after Y2K), computer crime investigation (document everything), computer incident response teams (CIRTs, vague), intrusion detection (vague and repetitious), and operational forensics (retain evidence and data). Observant readers will have noted a fair amount of duplication in that list. In fact, the reiteration of content is worse than appears here, since many topics rely on others, and certain basic ideas (Kerberos operations, the Diffie-Hellman public key system, and risk management, for three examples) recur in a variety of other discussions, with differing levels of detail. As in any work this size a number of outright bizarre mistakes have occurred, like the table showing the file structure of an authentication database, which has been swapped with the structural diagram of a completely different authentication system. This is the closest thing there is to a textbook for the CISSP exam. It is fairly easy to see which sections have been reproduced in the ISC(2) (International Information System Security Certification Consortium) course (in some cases complete down to specific errors). Intriguingly, there are sections of the course that previously were covered by the third edition, and which do not appear in any significant form in this work. (An example is the discussion of the standard formal security models, such as Bell-La Padula and Clark-Wilson.) It should be noted that there is a significant difference in character between the two volumes. The first volume deals with topics that are closer to the heart of security, and the essays are generally more valuable to the practitioner. Volume two contains papers over a wider range of subjects, many of which (with the notable exception of the pieces on cryptography) have little or no relevance to security beyond fundamental concerns that are well covered elsewhere. Book one will be useful to the CISSP candidate and any specialty security worker: book two may be of interest to a narrower group of senior security executives and theorists, and, ironically, a wider audience of those interested in newer technologies in general. The quantity of good information that is contained in the work is definitely worth the price, but there could easily be a wholesale pruning of deadwood. copyright Robert M. Slade, 2001 BKINSCMH.RVW 20010609 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
Please report problems with the web pages to the maintainer