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 last sentence is right on. djf] From: CMESSALL <CMESSALL@mykotronx.com> Walter Cronkite: "...Unfortunately, security and liberty form a zero-sum equation. The inevitable trade-off: to increase security is to decrease liberty and vice versa. In the past, such trade-offs have been temporary — for the duration of the crisis of the moment. But today, we cannot see an end to the War on Terrorism, and that forces us to decide how secure we have to be and how free we want to be." Wow, have we already forgotten Ben Franklin's statement: "People who are willing to trade security for freedom soon find out that they have neither."? In all fairness to Walter (who, I would have thought, might have actually *heard* Ben say those magic words ;-)), the trade-off might be correct at any given point in time, for the technology that applies at that instant. The secret of course is to change the rules (i.e., the technology) so that we can have more security AND retain our liberty. - Chuck Messall IP Archives at: http://www.interesting-people.org/archives/interesting-people/
Thanks to many of you who responded thoughtfully to my plaintive cries of
Spam-woe. The simplest approach something that I have been contemplating
for some time is to suggest that, if you want to significantly raise the
probability that your message to RISKS will not be ignored, use the current
string to include in the subject line. "RISKS" itself in the subject line
is less than ideal, because a surprising number of spams actually include
that. But for the foreseeable future, to radically improve my well-being
and ability to separate the wheat from the chaff, let's try the string
notsp:
in the subject line followed by a meaningful subject, or perhaps "notsp"
appended to the subject line (CASE INSENSITIVE). This pass-string will
remain relatively stable unless it gets abused, in which case I will
announce a phased-in change. Many thanks for putting up with this
inconvenience.
Other remedies were suggested by RISKS readers (although some of them
are not really suitable for RISKS-types of operations):
* Greylisting
<http://projects.puremagic.com/greylisting/>
* Spambayes
<http://spambayes.sf.net>
(following the inspiration of Graham, extensively tested and improved)
* Indirection to a Web page that has the CURRENT valid address that
changes as needed, plus procmail filters
* TMDA anti-spam challenge-response software
<http://tmda.net>
* Client-side POPFile proxy (open source, cross-platform)
<http://popfile.sourceforge.net>
* Bogofilter and various other filters
* Just change your e-mail address as often as desired, and notify your
regular communicators (clearly not applicable for RISKS, which
graciously receives e-mail from first-time contributors and needs
the stability of a permanent address).
An important concept in any such approach is that YOU should have flexible
control over it, rather than some third-party who tells you what you should
be willing to accept or reject. There is no one-size-fits-all. However,
* Tripoli is a flexible approach that could help significantly.
<http://www.pfir.org/tripoli-overview>
California's new anti-spam law may face the same fate as a similar law in Utah earlier this year. Kevin Johnson of the e-mail marketing company Digital Impact warns: "Hard-core spam will still come through, but legitimate companies will be more hesitant to send e-mail"; he also warns that when companies try to determine whether e-mail recipients live in California, spammers and advertisers may be forced to learn more about consumers, thereby reducing privacy. E-mail marketer Trevor Hughes suggests that the only answer is national legislation to harmonize spam laws in more than 30 states. [*USA Today*, 24 Sep 2003; NewsScan Daily, 25 Sep 2003] http://www.usatoday.com/tech/news/2003-09-24-spam_x.htm
I just finished a first cut at a FAQ on worms and worm containment (my obsession for the last couple of years). It may be of interest to RISKS readers: http://www.NetWorm.org/faq/ Stuart Staniford, President Tel: 707-445-4355 x 15 Silicon Defense - The Cyberwar Defense Company
Paul Festa, Staff Writer, CNET News.com, 23 Sep 2003 A federal jury has convicted a Florida man of violating the Digital Millennium Copyright Act, in the first jury-trial conviction under the controversial law, according to a U.S. attorney's office. The Los Angeles jury found 38-year-old Thomas Michael Whitehead guilty on Friday of selling hardware that could access DirecTV satellite broadcasts without paying for them, according to the U.S. attorney's office in Los Angeles. Whitehead, who was also known by his computer name "JungleMike," was convicted on one count of conspiracy, two counts of selling hardware that unlawfully decrypted the broadcasts, and three counts of violating the DMCA. With the six felony convictions, Whitehead faces up to 30 years in federal prison and fines of as much as $2.75 million. Sentencing is scheduled for Jan. 26, 2004. ... http://news.com.com/2100-1025-5080807.html
Here's some good news out of Florida. Broward County is lobbying for approval of printers for touchscreens, and one of their election officials expresses regret for purchasing them in the first place. Here's an excerpt: The touch-screen machinery accounted for part of the problems in the 2002 elections in Broward. During the September primary, election workers found more than 1,000 votes that had not been reported in initial tallies to the state because machines had not been shut down properly. And then in the November election, officials botched the numbers by not including in the tallies ballots cast by English-speaking early voters. "Hindsight is 20/20, but I wish we had stayed with optical scan," Commissioner Kristin Jacobs said. Source: Broward considers dumping $17 million in touch voting machines, Scott Wyman, 24 Sep 2003, *South Florida Sun-Sentinel* <Sun-Sentinel.com> Kim Alexander, President, California Voter Foundation kimalex@calvoter.org, 916-441-2494, http://www.calvoter.org
ELECTION THEFT 2000! A NEW BOMBSHELL!: A Diebold Voting Machines in Volusia County, Florida, Tallied a Vote-Count of -16,022. That's NEGATIVE 16,022: When will this all-important story break out in the US mainstream press? When will the Democrats confront the issue? What is at stake here is the future of democracy. Diebold Internal Support Memos [The original article to which this post refers was originally published on 29 Nov 2000 in *USA Today* by Philip Meyer. When I did a search for the article on the www.usatoday.com website I came up with this page which clearly provides the details of the article and even offers a link to a free preview of the article. However, when you click on the link, it gives you a page void of the article. What happened to it? One can only speculate. Nevertheless, I have obtained the original article. BMPB] [Contact Brent Beleskey <voterscoalition@rogers.com> for the article, PGN] A remarkable exchange concerning Diebold's voting machines in Volusia County, Florida: On January 17, 2001, Lana Hines, a county elections official sends out an inquiry as to how Al Gore ended up with a vote-count of -16,022. That's NEGATIVE 16,022 — which just happens also to have been the total number of votes cast for various independent and third-party candidates who also ran. (It was the largest number of such votes cast in Volusia County's history.) Pay close attention to the final entry, from "Tab" (Talbot) Iredale, Vice President of Research & Development at Global/Diebold: ...The error could only occur in one of four ways: 1.Corrupt memory card. This is the most likely explanation for the problem but since I know nothing about the 'second' memory card I have no ability to confirm the probability of this. 2.Invalid read from good memory card. This is unlikely since the candidates['] results for the race are not all read at the same time and the corruption was limited to a single race. There is a possib[ili]ty that a section of the memory card was bad but since I do not know anything more about the 'second' memory card I cannot validate this. 3.Corruption of memory, whether on the host or Accu-Vote. Again this is unlikely due to the localization of the problem to a single race. 4.Invalid memory card (i.e., one that should not have been uploaded). There is always the possib[i]lity that the 'second memory card' or 'second upload' came from an unauthorised source. And that's only the tip of the iceberg.
[Admittedly this is a story from mainlaind China, and stories from there are often mistranslated linguistically and culturally when they reach English- language papers. But it appeared in the quality Hong Kong daily. It would seem reasonable to assume that their staff can read the original, and not make too many mistakes in the translation.] Woman wins case against in-law for ID cancellation A 98-year-old woman will be paid damages for psychological injury inflicted by her daughter-in-law, a Beijing court has ruled. The *Beijing Daily* reports that the elderly woman discovered her relative cancelled her identity registration card seven years ago. The defendant claims she cancelled the card to ensure her mother-in-law would not be cremated after she died. Cancelling the card made the woman non-existent in the eyes of the law. Source: *South China Morning Post*, dateline Beijing, 26 Sep 2003 [They have a closed web-site, so I can't find the URL] Roger Clarke http://www.anu.edu.au/people/Roger.Clarke/ +61 2 6288 1472 Xamax Consultancy Pty Ltd, 78 Sidaway St, Chapman ACT 2611 AUSTRALIA
The Five Dumbest Things on Wall Street This Week By George Mannes, Senior Writer, 3 Oct 2003 http://www.thestreet.com/markets/dumbestgm/10117038.html [George sent RISKS an excerpt, namely, the FIRST of five dumbest things. I had difficulty trying to abridge it for RISKS, and decided to include it in its entirety. See the URL for the other four. PGN] 1. I Dream of the Gini Index We at the Five Dumbest Things Research Lab hate to go all anti-academic on you, but here's a little advice: The next time you see a statistic in the newspaper, don't believe it. It's wrong. OK, OK. That's overstating our case a little. It's not necessarily wrong. But it's not right, either. Exhibit A: The 2002 household income figures released last Friday by the U.S. Census Bureau. The takeaway from the report, as you may have read in *The Wall Street Journal*'s Monday account, was that the poverty level rose, but income inequality didn't, because rich folk's income took a beating, too. But something further down in the write-up caught our eye. "Difficulties in recording seven-figure incomes," reported the Journal, might have resulted in underreported income among the wealthiest Americans. In other words, the rich may be richer. That's odd, we thought. People pay a lot of attention to these annual income-disparity figures. How come no one's getting worked up about inaccurate data from such a key segment of the surveyed population? This can't be true. We called up Edward Welniak, chief of the Census Bureau's income survey, to check. Indeed, there are difficulties with high-income data, Welniak told us. Here's why: Starting with the 1993 numbers, the bureau's staff — which interviews a sample of 78,000 households for the income survey either in person or over the phone — has been entering people's responses directly into portable or desktop PCs. As part of the survey, respondents are asked to report how much money they made the previous year from numerous sources -- stuff like the job held the longest, interest and dividends. And here's the catch: In each category, the highest dollar amount one can enter is $999,999. So let's say a Census employee had dropped by the $15,000-umbrella-stand- festooned apartment of ousted Tyco Chairman Dennis Kozlowski in 2001. And let's say the then-executive wanted to report the $50 million or so in undisclosed compensation the Securities and Exchange Commission says he received in 2000. Well, Kozlowski couldn't have done it. The Census would have recorded his salary at a mere million bucks. "The fact that we're not recording the full dollar value is going to understate the share of income controlled by households at the highest levels," says Welniak. But, says Welniak, there's a good reason for capping monetary entries at six digits: It limits the potential for error. One extra digit at the high end, and you're talking about, say, a $9 million paycheck instead of a $900,000 payout. Errors at the high end of the income scale have a much larger impact than errors at the bottom. The increased accuracy introduced by more possible digits, says Welniak, would be more than offset by the decreased accuracy from newly enabled errors. Welniak has even investigated the exact effect of rounding all multimillion-dollar income sources down to a megabuck. According to his analysis of numbers from 1999 — a year for which 26 respondents reported employment compensation of at least $1 million in at least one category -- data-entry limitations effectively understated income inequality by 1%, using a standard measure of income distribution known as the Gini Index. But, given that the error appears to be constant year after year, says Welniak, "Measuring changes in income inequality from one year to the next is not going to be affected." In other words, ignore the absolute number and look at the trend. Mindful of that, we point out that over the past decade, the Census Bureau's Gini Index has been creeping upward — implying increased income inequality. Starting at 45.4 in 1993, it peaked at 46.6 in 2001 but retreated to 46.2 last year. (For purposes of comparison, the United Nations Development Program — which puts the U.S. at 40.8 — says Japan is a 24.9 and Brazil is a 60.7.) In fact, someone has gotten worked up about the low-balled high incomes: the Center on Budget and Policy Priorities, a D.C.-based research group. The CBPP has been complaining about the Census data for years, griping not only about the $999,999 cap but also about the Bureau's exclusion of capital gains from household income. "The census data has useful information," says Isaac Shapiro, a CBPP senior fellow. "But at the high end, it's not useful." Based on Congressional Budget Office data, the CBPP says the average household after-tax income in the top 1% of the population tripled from $286,000 in 1979 to $863,000 in 2000, while the lowest fifth of the population saw household income rise a mere $1,100 to $13,700 over the same time period. Put that in your Gini Index and smoke it. George Mannes, 14 Wall Street - 15th Floor / New York, NY 10005 phone: 212-321-5208 / mobile: 646-641-2093 http://find.thestreet.com/cgi-bin/texis/author/?au=A0000332
Yesterday, I got an e-mail message from Amazon.com which I am including here
in full (word wrapped and with some details obscured but otherwise
unmodified) because I believe it will be of interest to RISKS readers.
Additional comments from me follow the message.
X-AMAZON-TRACK: <jik@kamens.brookline.ma.us>
Date: Thu, 4 Sep 2003 16:01:07 -0700
From: charge-inquiries@amazon.com
To: jik@kamens.brookline.ma.us
Cc: charge-inquiries@amazon.com
Subject: Your Credit Card Account
Greetings from Amazon.com.
We perform routine reviews of orders to protect our customers. During one
of these reviews we discovered that an account was opened with a card used
by you on another account. For your reference the card in question is a
American Express card with the last five digits of [deleted].
As it appears the card was used without your authorization, we have closed
this new account and cancelled any outstanding orders. If the account is
indeed yours, we apologize for any inconvenience caused and ask that you
notify us by replying to this email message as soon as possible. If the
card was used without your authorization, we recommend you cancel the card
immediately by contacting the financial institution that issued the card.
Unfortunately, if this is the situation, you should know that a charge in
the amount of $556.94 was processed by us.
You should review all recent charges made to this card, reporting any
unauthorized charges, including those mentioned above, to your financial
institution. The financial institution, in turn, will send you forms to
formally dispute the unauthorized charges, the applicable merchants will
be notified and charged back, and your account subsequently credited.
Additionally, you may wish to report this matter to the applicable law
enforcement agency.
We were able to verify that your card was not compromised from our site.
Our credit and debit card data is stored on a computer that is not
connected to the Internet. When data is received it is sent to a
dedicated computer via a proprietary one-way interface across a simple
serial connection. The information is stored no other place, access to
the data is restricted and, when accessed, logged.
Although we are not permitted to provide you with any details about the
unauthorized use, we will provide this information to any law enforcement
agency investigating this matter as well as to the financial institution.
Please don't hesitate to contact us if you have any further questions or
concerns.
Sincerely,
Ben
Investigation Specialist
Amazon.com
http://www.amazon.com
Earth's Biggest Selection
=========================
I went to the American Express Web site and checked the unbilled activity on
the card, and, indeed, found a charge of $556.94 to Amazon.com on August 31
which I did not make. I also found another charge I did not make of over
$500 to Amazon.com on August 27.
I called the telephone number on the back of my card, navigated through
voice-mail for several minutes and then spoke to three representatives. The
first deactivated my card, issued me a new one, and transferred me to the
customer service department. The customer service rep transferred me to the
fraud department. The fraud rep ask me a few questions that were probably
from a script ("Was your card ever out of your possession?" "Did you make
these charges?", etc.). Then she said that the charges would be removed
from my account and investigated.
Some things here worked very well. It's good that Amazon caught the bogus
charges relatively quickly and notified me about them. It's good that
American Express was polite and was able to deactivate my card, issue me a
new one, and remove the bogus charges from my account quickly.
Some things did not work so well. Why didn't Amazon stop the perpetrators
in real-time from making a purchase using a card already registered to
another account, as opposed to only detecting the situation after the fact?
Since I assume that the fraudulent purchase was shipped to an address other
than mine, why didn't Amazon require additional verification before shipping
over $500 of merchandise to an address other than the card's billing
address?
There are some questions whose answers I do not know, and neither Amazon nor
American Express is telling. Did the perpetrator use my name? Did s/he
know my correct billing address? Did s/he know the security code printed on
the front of the card? And if the answer to any of these questions is "no,"
why did Amazon allow the charge? And the biggest question, to which I'll
probably never know the answer, is, how did the perpetrator steal my info?
Even if they catch him/her and find out, it's unlikely that the information
will trickle back to me.
Today I'll be contacting all the credit-reporting agencies to put a fraud
alert on my report and ask them for free copies so that I can verify that
this is merely a case of isolated credit-card number fraud as opposed to
full-scale identity theft. Who knows, this may be the start of a very bumpy
ride.
Jonathan Kamens
About a week ago, our front door was broken down at 3 in the morning. The burglars took my wife's handbag from the hall and ran (luckily, it didn't contain her car keys, because a common strategy is to return in a few hours and take the car, too). Today, we received a number of phone contracts. These may or may not have been paid for with the stolen credit cards [1], but (we are informed) the credit cards were used for ID. This got me thinking. My credit cards are often used for ID, too. But they never check whether the card has been stolen - all they check is that it has the right name on it. Now, given that the most common case of this occurring is when I take internal flights in the UK, I'm suddenly worried. The risk is obvious. Incidentally, the incidents also show the lack of value of photo ID - at least one of the contracts requires proof of address, and the only proof in the handbag was my wife's driving licence. Which has a photo on it. So I guess we can add that as a second risk (i.e. relying on photo IDs for fraud prevention). [1] Since my wife spent the time waiting for the police cancelling all her cards, they may not have been used. http://www.apache-ssl.org/ben.html http://www.thebunker.net/
BKINDTSN.RVW 20030901
"Intrusion Detection with Snort", Jack Koziol, 2003, 1-57870-281-X,
U$45.00/C$69.99/UK#32.99
%A Jack Koziol
%C 201 W. 103rd Street, Indianapolis, IN 46290
%D 2003
%G 1-57870-281-X
%I Macmillan Computer Publishing (MCP)
%O U$45.00/C$69.99/UK#32.99 800-858-7674 info@mcp.com
%O http://www.amazon.com/exec/obidos/ASIN/157870281X/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/157870281X/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/157870281X/robsladesin03-20
%P 340 p.
%T "Intrusion Detection with Snort"
Chapter one is a good introduction to the basics of intrusion detection,
although it is odd that the list of detection methods is missing some
important entries, such as heuristic rule-based and statistical methods.
The background overview of Snort, in chapter two, describes alerts, related
applications, and even has recommendations for sensor net architecture.
Most of the content in regard to the components of Snort, in chapter three,
deals with the preprocessors, and various attack signatures. Chapter four's
advice about planning for the installation of Snort is broadly based,
addressing policy, architecture, and even incident response, but the
material is quite abstract, and could have benefitted from more practical
examples. Some of these missing considerations are dealt with in chapter
five, which looks at hardware and operating system factors. The text
concentrates on server and sensor performance, but also addresses the
network connection. Directions on building a Snort server under Red Hat
Linux version 7.3 are given in chapter six. The sensor and console
instructions are provided in chapters seven and eight, respectively. A few
optional architectures are described in chapter nine.
Chapter ten deals with tuning various rulesets and components in order to
reduce the level of false alarms. Creating real-time alert systems is
discussed in chapter eleven. Chapter twelve is a major one, outlining the
creation and modification of rules for filtering and analyzing traffic.
Chapter thirteen is supposed to be about upgrading and maintaining Snort,
but concentrates on ancillary management tools. Advanced or unusual
configurations of Snort are described in chapter fourteen.
The book is generally lucidly written and easy to study, but it contains
many typographical errors and a great deal of clumsy wording in the text.
Better copy editing word have improved readability, as well as confidence in
the reliability of various commands and settings. However, the meaning is
usually clear, even if the expression is sometimes jarring. For those
planning to use Snort, this should be a serviceable introduction.
copyright Robert M. Slade, 2003 BKINDTSN.RVW 20030901
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