CRYPTO-GRAM, January 15, 2004

Bruce Schneier <[email protected]> Thu, 15 Jan 2004 03:40:25 -0600
Newsgroups gmane.comp.security.crypto-gram
Message-ID <[email protected]>
                  CRYPTO-GRAM

               January 15, 2004

               by Bruce Schneier
                Founder and CTO
       Counterpane Internet Security, Inc.
            [email protected]
            <http://www.schneier.com>
           <http://www.counterpane.com>


A free monthly newsletter providing summaries, analyses, insights, and=20
commentaries on security: computer and otherwise.

Back issues are available at=20
<http://www.schneier.com/crypto-gram.html>.  To subscribe, visit=20
<http://www.schneier.com/crypto-gram.html> or send a blank message to=20
[email protected].


** *** ***** ******* *********** *************

In this issue:
      Color-Coded Terrorist Threat Levels
      Crypto-Gram Reprints
      Fingerprinting Foreigners
      News
      Terrorists and Almanacs
      Counterpane News
      More "Beyond Fear" Reviews
      Security Notes from All Over: President Musharraf and
        Signal Jammers
      WEIS
      New Credit Card Scam
      Diverting Aircraft and National Intelligence
      Comments from Readers


** *** ***** ******* *********** *************

       Color-Coded Terrorist Threat Levels


 From 21 December 2003 to 9 January 2004, the national threat level --=20
as established by the U.S. Department of Homeland Security -- was=20
Orange.  Orange is one level above Yellow, which is as low as the=20
threat level has gotten since the scale was established in the months=20
following 9/11.  There are two levels below Yellow.  There's one level=20
above Orange.

This is what I wrote in Beyond Fear:  "The color-coded threat alerts=20
issued by the Department of Homeland Security are useless today, but=20
may become useful in the future.  The U.S. military has a similar=20
system; DEFCON 1-5 corresponds to the five threat alerts levels: Green,=20
Blue, Yellow, Orange, and Red.  The difference is that the DEFCON=20
system is tied to particular procedures; military units have specific=20
actions they need to perform every time the DEFCON level goes up or=20
down.  The color-alert system, on the other hand, is not tied to any=20
specific actions.  People are left to worry, or are given nonsensical=20
instructions to buy plastic sheeting and duct tape.  Even local police=20
departments and government organizations largely have no idea what to=20
do when the threat level changes.  The threat levels actually do more=20
harm than good, by needlessly creating fear and confusion (which is an=20
objective of terrorists) and anesthetizing people to future alerts and=20
warnings.  If the color-alert system became something better defined,=20
so that people know exactly what caused the levels to change, what the=20
change means, and what actions they need to take in the event of a=20
change, then it could be useful.  But even then, the real measure of=20
effectiveness is in the implementation.  Terrorist attacks are rare,=20
and if the color-threat level changes willy-nilly with no obvious cause=20
or effect, then people will simply stop paying attention.  And the=20
threat levels are publicly known, so any terrorist with a lick of sense=20
will simply wait until the threat level goes down."

Living under Orange reinforces this.  It didn't mean anything.  Tom=20
Ridge's admonition that Americans "be alert, but go about their=20
business" reinforces this; it's nonsensical advice.  I saw little that=20
could be considered a good security trade-off, and a lot of draconian=20
security measures and security theater.

I think the threat levels are largely motivated by politics.  There are=20
two possble reasons for the alert.

Reason 1: CYA.  Governments are naturally risk averse, and issuing=20
vague threat warnings makes sense from that perspective.  Imagine if a=20
terrorist attack actually did occur.  If they didn't raise the threat=20
level, they would be criticized for not anticipating the attack.  As=20
long as they raised the threat level they could always say "We told you=20
it was Orange," even though the warning didn't come with any practical=20
advice for people.

Reason 2: To gain Republican votes.  The Republicans spent decades=20
running on the "Democrats are soft on Communism" platform.  They've=20
just discovered the "Democrats are soft on terrorism" platform.  Voters=20
who are constantly reminded to be fearful are more likely to vote=20
Republican, or so the theory goes, because the Republicans are viewed=20
as the party that is more likely to protect us.

(These reasons may sound cynical, but I believe that the Administration=20
has not been acting in good faith regarding the terrorist threat, and=20
their pronouncements in the press have to be viewed under that light.)

I can't think of any real security reasons for alerting the entire=20
nation, and any putative terrorist plotters, that the Administration=20
believes there is a credible threat.


** *** ***** ******* *********** *************

             Crypto-Gram Reprints



Crypto-Gram is currently in its seventh year of publication. Back=20
issues cover a variety of security-related topics, and can all be found=20
on <http://www.schneier.com/crypto-gram.html>.  These are a selection=20
of articles that appeared in this calendar month in other years.

Militaries and Cyber-War:
<http://www.schneier.com./crypto-gram-0301.html#1>

A cyber Underwriters Laboratories?
<http://www.schneier.com/crypto-gram-0101.html#1>

Code signing:
<http://www.schneier.com/crypto-gram-0101.html#10>

Block and stream ciphers:
<http://www.schneier.com/crypto-gram-0001.html#Blockbuster>


** *** ***** ******* *********** *************

           Fingerprinting Foreigners



Imagine that you're going on vacation to some exotic country.  You get=20
your visa, plan your trip, and take a long flight.  How would you feel=20
if, at the border, you were photographed and fingerprinted?  How would=20
you feel if your biometrics stayed in that country's computers for=20
years?  If your fingerprints could be sent back to your home=20
country?  Would you feel welcomed by that country, or would you feel=20
like a criminal?

This week the U.S. government began doing just that to an expected 23=20
million visitors to the U.S.  The US-VISIT program is designed to=20
capture biometric information at our borders.  Only citizens of 27=20
countries who don't need a visa to enter the U.S., mostly in Europe,=20
are exempt.  Currently all 115 international airports and 14 seaports=20
are covered, and over the next three years this program will be=20
expanded to cover at least 50 land crossings, and also to screen=20
foreigners exiting the country.

None of this comes cheaply.  The program cost $380 million in 2003 and=20
will cost at least the same in 2004.  But that's just the start; the=20
Department of Homeland Security's total cost estimate nears $10 billion.

According to the Bush administration, the measures are designed to=20
combat terrorism.  As a security expert, it's hard for me to see=20
how.  The 9/11 terrorists would not have been deterred by this system;=20
many of them entered the country legally on valid passports and=20
visas.  We have a 5,500-mile long border with Canada, and another=20
2,000-mile long border with Mexico.  Two-to-three-hundred thousand=20
people enter the country illegally each year from=20
Mexico.  Two-to-three-million people enter the country legally each=20
year and overstay their visas.  Capturing the biometric information of=20
everyone entering the country doesn't make us safer.

And even if we could completely seal our borders, fingerprinting=20
everyone still wouldn't keep terrorists out.  It's not like we can=20
identify terrorists in advance.  The border guards can't say =93this=20
fingerprint is safe; it's not in our database=94 because there is no=20
comprehensive fingerprint database for suspected terrorists.

More dangerous is the precedent this program sets.  Today the program=20
only affects foreign visitors with visas.  The next logical step is to=20
fingerprint all visitors to the U.S., and then everybody, including=20
U.S. citizens.

Following this train of thought quickly leads to sinister=20
speculation.  There's no reason why the program should be restricted to=20
entering and exiting the country; why shouldn't every airline flight be=20
"protected?"  Perhaps the program can be extended to train rides, bus=20
rides, entering and exiting government buildings.  Ultimately the=20
government will have a biometric database of every U.S. citizen--face=20
and fingerprints--and will be able to track their movements.  Do we=20
want to live in that kind of society?

Retaliation is another worry.  Brazil is now fingerprinting Americas=20
who visit that country, and other countries are expected to follow=20
suit.  All over the world, totalitarian governments will use the our=20
fingerprinting regime to justify fingerprinting Americans who enter=20
their countries.  This means that your prints are going to end up on=20
file with every tin-pot dictator from Sierra Leone to Uzbeckistan.  And=20
Tom Ridge has already pledged to share security information with other=20
countries.

Security is a trade-off.  When deciding whether to implement a security=20
measure, we must balance the costs against the benefits.  Large-scale=20
fingerprinting is something that doesn't add much to our security=20
against terrorism, costs an enormous amount of money that could be=20
better spent elsewhere.  Allocating the funds on compiling, sharing,=20
and enforcing the terrorist watch list would be a far better security=20
investment.  As a security consumer, I'm getting swindled.

America's security comes from our freedoms and our liberty.  For over=20
two centuries we have maintained a delicate balance between freedom and=20
the opportunity for crime.  We deliberately put laws in place that=20
hamper police investigations, because we know we are a more secure=20
because of them.  We know that laws regulating wiretapping, search and=20
seizure, and interrogation make us all safer, even if they make it=20
harder to convict criminals.

The U.S. system of government has a basic unwritten rule: the=20
government should be granted only limited power, and for limited=20
purposes, because of the certainty that government power will be=20
abused.  We've already seen the US-PATRIOT Act powers granted to the=20
government to combat terrorism directed against common=20
crimes.  Allowing the government to create the infrastructure to=20
collect biometric information on everyone it can is not a power we=20
should grant the government lightly.  It's something we would have=20
expected in former East Germany, Iraq, or the Soviet Union.  In all of=20
these countries greater government control meant less security for=20
citizens, and the results in the U.S. will be no different.  It's bad=20
civic hygiene to build an infrastructure that can be used to facilitate=20
a police state.


A version of this essay originally appeared in Newsday.
<http://www.newsday.com/news/opinion/ny-vpsch143625202jan14,0,1880923.st=20
ory> or <http://tinyurl.com/2yy7t>

Office of Homeland Security webpage for the program:
<http://www.dhs.gov/dhspublic/interapp/editorial/editorial_0333.xml>

News articles:
<http://www.washtimes.com/national/20031201-115121-4339r.htm>
<http://www.washtimes.com/national/20031027-112510-5818r.htm>
<http://www.nytimes.com/reuters/news/news-security-usa-visas.html>
<http://gcn.com/vol1_no1/daily-updates/24536-1.html>
<http://www.sunspot.net/news/custom/attack/bal-airport0106,0,42711.story>
<http://www.cnn.com/2004/US/01/04/visit.program/>
<http://www.nytimes.com/2004/01/05/national/05CND-SECU.html>
<http://www.ilw.com/lawyers/immigdaily/doj_news/2004,0106-hutchinson.shtm>
<http://www.theage.com.au/articles/2004/01/06/1073268031785.html>
<http://www.thestar.co.za/index.php?fSectionId=3D132&fArticleId=3D318749>
<http://www.ilw.com/lawyers/articles/2003,1231-krikorian.shtm>

Opinions:
<http://news.mysanantonio.com/story.cfm?xla=3Dsaen&xlb=3D1020&xlc=3D1074396>
<http://www.rockymountainnews.com/drmn/opinion/article/0,1299,DRMN_38_24=20
75765,00.html> or <http://tinyurl.com/3bqze>
<http://www.shusterman.com/pdf/advocacy61703.pdf>
<http://www.washingtontechnology.com/ad_sup/homeland-coalition/2.html>

Brazil fingerprints U.S. citizens in retaliation:
<http://reprints.msnbc.com/id/3875747/>


** *** ***** ******* *********** *************

                      News



Yahoo is planning on combating spam by requiring e-mail to be=20
authenticated.  The problem, they claim, is that there's no way of=20
knowing who the sender really is.  It seems obvious to me that this=20
won't stop spam at all.  Spammers are already breaking into computers=20
and hijacking legitimate users' e-mail systems.  Spammers are already=20
sending mail out of random countries and stolen accounts.  How exactly=20
will this make things better?
<http://www.newscientist.com/news/news.jsp?id=3Dns99994459>
<http://edition.cnn.com/2003/TECH/internet/12/05/spam.yahoo.reut/>

Regularly I've written that secrecy is more often harmful to security=20
than helpful.  This article discusses that: the Bush Administration is=20
using terrorism as an excuse to keep many aspects of government secret,=20
but the real threat is more often the government itself.
<http://www.usnews.com/usnews/issue/031222/usnews/22secrecy.htm>

Here's some good Microsoft news.  The new update to Windows XP will=20
include the Internet Connection Firewall (ICF).  It will be on by=20
default and more rigorous in its protection.  Seems like a security=20
improvement to me.
<http://www.eweek.com/article2/0,4149,1413404,00.asp>

OnStar, the communications and navigation system in GM cars, can be=20
used to surreptitiously eavesdrop on passengers:
<http://www.newsmax.com/archives/articles/2003/12/10/213653.shtml>

More TSA absurdity:
<http://www.post-gazette.com/pg/03362/255283.stm>

And the British react to a decision to put sky marshals on selected=20
flights into the U.S.:
<http://www.channelnewsasia.com/stories/afp_world/view/64011/1/.html>

Interesting article on a computer security researcher who is using=20
biological metaphors in an effort to create next-generation=20
computer-security tools.  This is interesting work, but I am skeptical=20
about a lot of it.  The biological metaphor works only marginally well=20
in the computer world.  Certainly the monoculture argument makes sense=20
in the computer world, but biological security is generally based on=20
sacrificing individuals for the good of the species -- which doesn't=20
really apply in the computer world.
<http://www.computerworld.com/securitytopics/security/story/0,10801,8835=20
9,00.html> or <http://tinyurl.com/2bwah>

There's two interesting aspects to this case.  First, the judge ruled=20
that a player has a claim of ownership to virtual property in computer=20
game.  And second, the software company was partially liable for=20
damages because of bugs in their code.  The case was in China, which=20
isn't much of a precedent for the rest of the world, but it is still=20
interesting news.
<http://story.news.yahoo.com/news?tmpl=3Dstory&u=3D/nm/20031219/wr_nm/entert=
=20
ainment_china_hacker_dc_1> or <http://tinyurl.com/3xsfq>

An interesting blackmail story.  "Cyber blackmail artists are shaking=20
down office workers, threatening to delete computer files or install=20
pornographic images on their work PCs unless they pay a ransom, police=20
and security experts said."
<http://www.cnn.com/2003/TECH/internet/12/29/cyber.blackmail.reut/index.=20
html> or <http://tinyurl.com/3924u>

An article on the future of computer security.  The moral is identical=20
to what I've been saying: things will get better eventually, but before=20
that things will get worse:
<http://www.computerworld.com/newsletter/0,4902,88646,00.html>

A story about security in the National Football League:
<http://www.csoonline.com/read/010104/nfl.html>

How to hack password-protected MS-Word documents.  Not only can you=20
view protected documents, you can also make changes to them and=20
reprotect them.  This is a huge security vulnerability.
<http://www.securityfocus.com/archive/1/348692/2004-01-02/2004-01-08/0>

Last month Bush snuck into law one of the provisions of the failed=20
PATRIOT ACT 2.  The FBI can now obtain records from financial=20
institutions without requiring permission from a judge.  The=20
institution can't tell the target person that his records were taken by=20
the FBI.  And the term "financial institution" has been expanded to=20
include insurance companies, travel agencies, real estate agents,=20
stockbrokers, the U.S. Postal Service, jewelry stores, casinos, and car=20
dealerships.
<http://www.wired.com/news/privacy/0,1848,61792,00.html>

Adobe has special code in its products to prevent counterfeiting.  I=20
think this is a great security countermeasure.  It's not designed to=20
defend against the professional counterfeiters, with their counterfeit=20
plates and special paper.  It's designed to defend against the amateur=20
counterfeiter, the hobbyist.  Color copiers have had=20
anti-counterfeiting defenses for years.  Raising the bar is a great=20
defense here.
<http://www.miami.com/mld/miamiherald/news/breaking_news/7674024.htm>


** *** ***** ******* *********** *************

           Terrorists and Almanacs



It's so bizarre it's almost self-parody.  The FBI issued a warning to=20
police across the nation to be on the watch for people carrying=20
almanacs, because terrorists may use these reference books "to assist=20
with target selection and pre-operational planning."

Gadzooks!  People with information are not suspect.  Almanacs,=20
reference books, and informational websites are not dangerous tools=20
that aid terrorism.  They're useful tools for all of us, and people who=20
use them are better people because of them.  I worry about alerts like=20
these, because they reinforce the myth that information is inherently=20
dangerous.

The FBI's bulletin:
<http://cryptome.org/fbi-almanacs.htm>

News article:
<http://www.sfgate.com/cgi-bin/article.cgi?file=3D/news/archive/2003/12/29=
=20
/national1426EST0580.DTL> or <http://tinyurl.com/29lxw>

Clever commentary:
<http://nielsenhayden.com/makinglight/archives/004361.html#004361>


** *** ***** ******* *********** *************

                Counterpane News



Counterpane continues to offer its Enterprise Protection Suite, which=20
combines Managed Security Monitoring with Managed Vulnerability=20
Scanning, fully outsourced Device Management, and Security Consulting=20
services, at a 15% discount to Crypto-Gram readers (and, by extension,=20
everyone):
<http://www.counterpane.com/cgi-bin/enterprise.cgi>

EMEA press release:
<http://www.counterpane.com/pr-20031217.html>

Schneier was chosen as Best Industry Spokesman by Info Security Magazine:
<http://infosecuritymag.techtarget.com/ss/0,295796,sid6_iss288_art514,00=20
.html> or <http://tinyurl.com/39wcg>

Q&A with Schneier in Infoworld:
<http://www.infoworld.com/article/03/12/12/49FEiw25luminaries_3.html>

Schneier essay on Blaster and the blackout (Salon.com):
<http://www.salon.com/tech/feature/2003/12/16/blaster_security/index_np.=20
html> or <http://tinyurl.com/26gpn>

Schneier op-ed essay on semantic attacks (San Jose Mercury News):
<http://www.bayarea.com/mld/mercurynews/7529172.htm>

Schneier's op-ed essay on casual surveillance and the loss of personal=20
privacy (Minneapolis Star-Tribune):
<http://www.startribune.com/stories/1519/4278339.html>


** *** ***** ******* *********** *************

           More "Beyond Fear" Reviews


"Beyond Fear" continues to sell well.  The book is going into its=20
second printing, so if it's not at your local bookstore, be patient for=20
a couple of weeks.

A new review:
<http://www.vnunet.com/Analysis/1151575>

Two different reviews from Computing Reviews:
<http://www.reviews.com/navigation.cfm?targetpage=3DReview&media_id=3D154298=
=20
7&review_id=3D128744> or <http://tinyurl.com/2l377>
<http://www.reviews.com/navigation.cfm?targetpage=3DReview&media_id=3D154298=
=20
7&review_id=3D128676> or <http://tinyurl.com/276be>

Book's website:
<http://www.schneier.com/bf.html>


** *** ***** ******* *********** *************

        Security Notes from All Over:
    President Musharraf and Signal Jammers



Attackers wired a bridge in Pakistan with explosives, intending to=20
detonate it when President Musharraf's motorcade drove over it.  But=20
according to a Pakistani security official, "The presidential motorcade=20
has special jamming equipment, which blocks all remote-controlled=20
devices in a 200-metre radius."

Unfortunately, by publishing this information in the paper, the jamming=20
equipment is unlikely to save him next time.

It's rare that secrecy is good for security, but this is an example of=20
it.  Musharraf's jamming equipment was effective precisely because the=20
attackers didn't expect it.  Now that they know about it, they're going=20
to use some other detonation mechanism: wires, cell phone=20
communications, timers, etc.

But maybe none of this is true.

Think about it: if the jamming equipment worked, why would the=20
Pakistani security tell the press?  There are several reasons.  One,=20
the bad guys found out about it, either when their detonator didn't=20
work or through some other mechanism, so they might as well tell=20
everybody.  Two, to make the bad guys wonder what other countermeasures=20
the motorcade has.  Or three, because the press story is so cool that=20
it's worth rendering the countermeasure ineffective.  None of these=20
explanations seems very likely.

There's another possible explanation: there's no jamming=20
equipment.  The detonation failed for some other, unexplained, reason,=20
and Pakistani security forces are pretending that they can block remote=20
detonations.

Deception is another excellent security countermeasure, and one=20
that--at least to me--is a more likely explanation of events.

<http://www.salon.com/news/wire/2003/12/17/musharraf/>


** *** ***** ******* *********** *************

                     WEIS



The Third Workshop on Economics and Information Security will be held=20
in Minneapolis in May.  This is currently my favorite security=20
conference.  I think that economics has a lot to teach computer=20
security, and it is very interesting to get economists, lawyers, and=20
computer security experts in the same room talking about issues.

Conference website:
<http://www.dtc.umn.edu/weis2004>

Websites for the First and Second Workshops, including many of the=20
papers presented:
<http://www.sims.berkeley.edu/resources/affiliates/workshops/econsecurit=20
y/> or <http://tinyurl.com/2t2gn>
<http://www.cpppe.umd.edu/rhsmith3/index.html>


** *** ***** ******* *********** *************

            New Credit Card Scam



This one is clever.

You receive a telephone call from someone purporting to be from your=20
credit card company.  They claim to be from something like the security=20
and fraud department, and question you about a fake purchase for some=20
amount close to $500.

When you say that the purchase wasn't yours, they tell you that they're=20
tracking the fraudsters and that you will receive a credit.  They tell=20
you that the fraudsters are making fake purchases on cards for amounts=20
just under $500, and that they're on the case.

They know your account number.  They know your name and address.  They=20
continue to spin the story, and eventually get you to reveal the three=20
extra numbers on the back of your card.

That's all they need.  They then start charging your card for amounts=20
just under $500.  When you get your bill, you're unlikely to call the=20
credit card company because you already know that they're on the case=20
and that you'll receive a credit.

It's a really clever social engineering attack.  They have to hit a lot=20
of cards fast and then disappear, because otherwise they can be=20
tracked, but I bet they've made a lot of money so far.


** *** ***** ******* *********** *************

   Diverting Aircraft and National Intelligence



Security can fail in two different ways.  It can fail to work in the=20
presence of an attack: a burglar alarm that a burglar successfully=20
defeats.  But security can also fail to work correctly when there's no=20
attack: a burglar alarm that goes off even if no one is there.

Citing "very credible" intelligence regarding terrorism threats, U.S.=20
intelligence canceled 15 international flights in the last couple of=20
weeks, diverted at least one more flight to Canada, and had F-16s=20
shadow others as they approached their final destinations.

These seem to have been a bunch of false alarms.  Sometimes it was a=20
case of mistaken identity.  For example, one of the "terrorists" on an=20
Air France flight was a child whose name matched that of a terrorist=20
leader; another was a Welsh insurance agent.  Sometimes it was a case=20
of assuming too much; British Airways Flight 223 was detained once and=20
canceled twice, on three consecutive days, presumably because that=20
flight number turned up on some communications intercept somewhere.  In=20
response to the public embarrassment from these false alarms, the=20
government is slowly leaking information about a particular person who=20
didn't show up for his flight, and two non-Arab-looking men who may or=20
may not have had bombs.  But these seem more like efforts to save face=20
than the very credible evidence that the government promised.

Security involves a trade-off: a balance of the costs and=20
benefits.  It's clear that canceling all flights, now and forever,=20
would eliminate the threat from air travel. But no one would ever=20
suggest that, because the trade-off is just too onerous. Canceling a=20
few flights here and there seems like a good trade-off because the=20
results of missing a real threat are so severe.  But repeatedly=20
sounding false alarms entails security problems, too.  False alarms are=20
expensive -- in money, time, and the privacy of the passengers affected=20
-- and they demonstrate that the "credible threats" aren't credible at=20
all.  Like the boy who cried wolf, everyone from airport security=20
officials to foreign governments will stop taking these warnings=20
seriously.  We're relying on our allies to secure international=20
flights; demonstrating that we can't tell terrorists from children=20
isn't the way to inspire confidence.

Intelligence is a difficult problem.  You start with a mass of raw=20
data: people in flight schools, secret meetings in foreign countries,=20
tips from foreign governments, immigration records, apartment rental=20
agreements, phone logs and credit card statements.  Understanding these=20
data, drawing the right conclusions -- that's intelligence.  It's easy=20
in hindsight but very difficult before the fact, since most data is=20
irrelevant and most leads are false.  The crucial bits of data are just=20
random clues among thousands of other random clues, almost all of which=20
turn out to be false or misleading or irrelevant.

In the months and years after 9/11, the U.S. government has tried to=20
address the problem by demanding (and largely receiving) more=20
data.  Over the New Year's weekend, for example, federal agents=20
collected the names of 260,000 people staying in Las Vegas=20
hotels.  This broad vacuuming of data is expensive, and completely=20
misses the point.  The problem isn't obtaining data, it's deciding=20
which data is worth analyzing and then interpreting it.  So much data=20
is collected that intelligence organizations can't possibly analyze it=20
all.  Deciding what to look at can be an impossible task, so=20
substantial amounts of good intelligence go unread and unanalyzed. Data=20
collection is easy; analysis is difficult.

Many think the analysis problem can be solved by throwing more=20
computers at it, but that's not the case.  Computers are dumb.  They=20
can find obvious patterns, but they won't be able to find the next=20
terrorist attack.  Al-Qaida is smart, and excels in doing the=20
unexpected.  Osama bin Laden and his troops are going to make mistakes,=20
but to a computer, their "suspicious" behavior isn't going to be any=20
different than the suspicious behavior of millions of honest=20
people.  Finding the real plot among all the false leads requires human=20
intelligence.

More raw data can even be counterproductive.  With more data, you have=20
the same number of "needles" and a much larger "haystack" to find them=20
in.  In the 1980s and before, East German police collected an enormous=20
amount of data on 4 million East Germans, roughly a quarter of their=20
population.  Yet even they did not foresee the peaceful overthrow of=20
the Communist government; they invested too heavily in data collection=20
while neglecting data interpretation.

In early December, the European Union agreed to turn over detailed=20
passenger data to the U.S. In the few weeks that the U.S. has had this=20
data, we've seen 15 flight cancellations.  We've seen investigative=20
resources chasing false alarms generated by computer, instead of=20
looking for real connections that may uncover the next terrorist=20
plot.  We may have more data, but we arguably have a worse security system.

This isn't to say that intelligence is useless.  It's probably the best=20
weapon we have in our attempts to thwart global terrorism, but it's a=20
weapon we need to learn to wield properly.  The 9/11 terrorists left a=20
huge trail of clues as they planned their attack, and so, presumably,=20
are the terrorist plotters of today.  Our failure to prevent 9/11 was a=20
failure of analysis, a human failure.  And if we fail to prevent the=20
next terrorist attack, it will also be a human failure.

Relying on computers to sift through enormous amounts of data, and=20
investigators to act on every alarm the computers sound, is a bad=20
security trade-off.  It's going to cause an endless stream of false=20
alarms, cost millions of dollars, unduly scare people, trample on=20
individual rights and inure people to the real threats.  Good=20
intelligence involves finding meaning among enormous reams of=20
irrelevant data, then organizing all those disparate pieces of=20
information into coherent predictions about what will happen next.  It=20
requires smart people who can see connections, and access to=20
information from many different branches of government.  It can't be=20
seen by the various individual pieces of bureaucracy; the whole picture=20
is larger than any of them.

These airline disruptions highlight a serious problem with U.S.=20
intelligence.  There's too much bureaucracy and not enough=20
coordination.  There's too much reliance on computers and=20
automation.  There's plenty of raw material, but not enough=20
thoughtfulness.  These problems are not new; they're historically=20
what's been wrong with U.S. intelligence.  These airline disruptions=20
make us look like a bunch of incompetents who cry wolf at the slightest=20
provocation.


This essay originally appeared in Salon.
<http://www.salon.com/opinion/feature/2004/01/09/security/>

News articles:
<http://www.usnews.com/usnews/issue/040112/usnews/12aviation.htm>
<http://www.napanews.com/templates/index.cfm?template=3Dstory_full&id=3D17DB=
=20
7A0D-A348-43AF-967D-8D2257117047> or <http://tinyurl.com/2utml>
<http://www.startribune.com/stories/484/4298735.html>
<http://www.contracostatimes.com/mld/cctimes/news/7635827.htm>
<http://www.reuters.com/newsArticle.jhtml?type=3DreutersEdge&storyID=3D40736=
70>
<http://www.smh.com.au/articles/2004/01/03/1072908948066.html>
<http://www.usatoday.com/news/world/2004-01-07-france-missed-flight_x.htm>


** *** ***** ******* *********** *************

               Comments from Readers



From: [email protected]
Subject: Blaster and the August 14th Blackout

I just read your article, and have an additional question worth knowing=20
about.

The article's hypothesis is that the massive blackout was indirectly=20
aided by alarm systems that failed due to MS Blast, and these failed=20
alarm systems allowed other equipment failures and adverse conditions=20
to go undetected by the power operators.  Because the technicians=20
didn't know about the adverse conditions, their hands were tied and=20
massive cascading failure resulted.

My question is, under normal circumstances, assuming the alarm systems=20
are operational, how often do equipment failures or adverse conditions=20
normally occur such that the alarm systems detect them in time, and=20
humans can intervene and head off massive cascading failures?

I suspect that if the computers were working that day, the technicians=20
would have learned about the alarm conditions, and they could have=20
headed off the catastrophe.  I just want to know how likely these alarm=20
conditions occur on a day-to-day basis.

In other words, how many problems occur that we, the general public,=20
don't ever hear about?

If we knew this probability metric, we could assess the relative hazard=20
of worms leading to widespread blackouts as a function of alarm=20
condition probability and alarm system/Internet interconnectedness.

I don't expect anyone to come forward to corroborate your hypothesis,=20
as that would be tantamount to an admission of failure by the=20
responsible IS/security staff, and likely grounds for=20
dismissal.  Perhaps some lone whistle blower might come out much later.



From: Andrew Odlyzko <[email protected]>
Subject: Computerized and Electronic Voting

The voting booth does provide some security against bribery and=20
coercion, but only as long as we can stop camera phones from being used=20
in them!



From: Fred Heutte <[email protected]>
Subject: Computerized and Electronic Voting

Thanks for your cogent thoughts on ballot security.  I almost=20
completely agree and was one of the first signers of David Dill's=20
petition.  I am also involved professionally in voter data -- from the=20
campaign side, with voter files, not directly with voting equipment --=20
but we're close enough to the vote counting process to see how it=20
actually works.

I would only disagree slightly in one area.  Absentee voting is quite=20
secure when looking at the overall approach and assessing the risks in=20
every part of the process.  As long as reasonable precautions like=20
signature checking are done, it would be difficult and expensive to=20
change the results of mail voting significantly.

For example, in Oregon, ballots are returned in an inside security=20
envelope which is sealed by the voter.  The outside envelope has a=20
signature area on the back side.  This is compared to the voter's=20
signature on file at the elections office.  The larger counties=20
actually do a digitized comparison, and back that up with a manual=20
comparison with a stratified random sample (to validate machine results=20
on an ongoing basis), as well as a final determination for any=20
questionable matches.

Certainly it is possible to forge a signature.  However, this=20
authentication process would greatly raise the cost of forged mail=20
ballots, absent consent of the voter.  In turn, interference or=20
coercion with absentee voting would require much higher travel costs=20
(at least) than doing so at a polling place, for a given change in the=20
outcome.

It is true that precincts have poll watchers, and absentee voters do=20
not.  But consider this.  Ballot boxes, which are often delivered by=20
temporary poll workers from the precinct to the elections office, are=20
occasionally stolen, but mail ballots are handled within a vast stream=20
of other mail by employees with paychecks and pensions at stake.  The=20
relatively low level of mail fraud inside the postal system is a=20
testament to its relative security, and the points where ballots are=20
aggregated for delivery to the elections office are usually on public=20
property and can also be watched by outside observers if need be.

Oregon has had some elections with 100% "vote by mail" since 1996, and=20
all elections since 1999.  So far, no verifiable evidence of voter=20
fraud has emerged, despite many checks and some predictions by those=20
with a political axe to grind that we would be engulfed in a wave of=20
election fixing.

The reality is that Oregon's system, which is based on some=20
common-sense security principles, has proven to be robust.  The one=20
lingering problem has been the need of some counties to make their=20
voters use punch cards at home because of their antiquated vote=20
counting equipment.  But while this is a vote integrity issue -- since=20
state statistics show a much higher undervote and spoiled ballot total=20
for punch cards as compared to mark-sense ballots -- it is not a=20
security issue per se.  And with Help America Vote Act (HAVA) funding=20
to convert to more modern vote counting systems, the Oregon chad=20
remains in only one county and will go extinct after 2004.

The mark-sense ("fill in the ovals") ballots we have work well, and=20
have low rates of over-votes and under-votes, despite the lack of=20
automated machine checking that is possible in well-designed precinct=20
voting systems.  This suggests that reasonable visual design and=20
human-friendly paper and pencil/pen home voting is a very reliable and=20
secure system.  When aided by automated counting equipment, we even=20
have the additional benefit of very fast initial counts.

The increase in voter participation in Oregon since the advent of=20
vote-by-mail -- 10 to 30 percentage points above national averages,=20
depending on the kind of election -- leads to the only other issue,=20
which is slow machine counts on election night after the polls close=20
due to the surge of late ballots received at drop-off locations around=20
the state.  Oregon in fact isn't really "vote by mail," it's=20
vote-at-home, with a paper ballot that can be mailed or left at any=20
official drop-off point in the state, including county election=20
offices, many schools and libraries, malls, town squares, etc.

The great advantage of the Oregon system is that it relies on the=20
principle that if you appeal to the best instincts of the citizen, the=20
overwhelming majority will "do our part" to ensure the integrity of the=20
democratic voting process, whether it is full consideration of the=20
candidates and issues before voting, watching to make sure all ballots=20
are securely transferred and counted, or favoring those laws and=20
policies that insure that everyone eligible can vote, that their votes=20
are counted, and that the candidates and measures with the most votes win.

The system is also cheaper than running traditional precinct=20
elections.  What's not to like?



From: Paul Rubin <[email protected]>
Subject: gambling machines vs. voting machines

The document at <http://gaming.state.nv.us/forms/frm141.pdf> shows what=20
anyone designing a new gambling machine (e.g. video poker machine) has=20
to do to get it certified in Nevada.  Note per page 4, all source code=20
for the game-specific parts of the machine must be submitted to the=20
gaming commission along with enough framework for the commission to=20
test it, and I'm told they actually examine it line by line (approval=20
takes about six months).  There are also specifications for the=20
physical security of the machines.

After deployment, the audit department apparently does random spot=20
checks, going into casinos and pulling out machines, making sure that=20
the EPROM images actually running in them are the same as the images=20
that were approved.  Four or five other states apparently do similar=20
examinations to certify equipment.  The rest of the states then go=20
along with what the main five or six gambling states decide.

It's bizarre that voting machine vendors squawk so much about getting=20
their code audited, since they face the same issues as gambling machine=20
vendors do (the purpose of the code review must be partly to make sure=20
the machine isn't sneakily grabbing a few extra points of revenue), and=20
the gambling machine vendors seem to tolerate the requirement.

There are also some federal standards about code certification for=20
firmware running inside medical implants or in avionics.  I'm trying to=20
find out more about that.  Voting machine code seems to have no=20
standards at all.



From: Arno Sch=E4fer <[email protected]>
Subject:  Modem hack

 > This is an old scam.  A man uses a computer virus to change
 > Internet dial-up numbers of victims' computers to special
 > premium rates, in an attempt to make a pile of money.  How he
 > thought that he wouldn't get caught is beyond me.

That remark is interesting.  In Germany, these so-called "dialer"=20
programs are an enormous problem, so much so that the German parliament=20
recently passed a special law in order to contain the deluge of these=20
scams.  Today, running a "dialer protection" tool is as essential to=20
German Internet users as having virus protection and a personal=20
firewall in place.  Apparently, the danger of getting caught and=20
prosecuted is small compared to the financial incentive for these=20
people.  One of the reasons for this is that it is often virtually=20
impossible to find out who is behind one of these "premium rate"=20
dial-up numbers.  There is a whole industry of sellers and resellers=20
for German premium rate numbers, many of which are in other countries,=20
far from German jurisdiction.  The fees for these calls (the most=20
blatant of which go up to $100 US per minute or up to $1000 US per=20
single call!) were collected with the regular phone bill.  When someone=20
discovered they had accidentally "contracted" a dialer program, it=20
often was impossible to track down the culprits, or it was already too=20
late and they had disappeared.  Moreover, you had to prove that you had=20
not deliberately activated the dialer program, as these were usually=20
declared as a "service" (e.g., in order to access adult content).  So=20
in fact having someone actually prosecuted for this kind of fraud was=20
rather the exception than the rule. Luckily, the legal position for=20
victims of these scams has markedly improved by now in Germany.



From: John Viega <[email protected]>
Subject: Amit Yoran

I was surprised in reading this month's Crypto-Gram to see you place=20
Amit Yoran in the doghouse for the following quote:

"For example, should we hold software vendors accountable for the=20
security of their code or for flaws in their code? In concept, that may=20
make sense. But in practice, do they have the capability, the tools to=20
produce more secure code?"

The only problem I personally see with this quote is that it doesn't=20
have enough context attached to it to make an absolute determination of=20
the intent. I do see how you could interpret it to mean, "It's=20
impossible to produce more secure code than we do today." However, just=20
from reading the quote, it seems that he's more saying that forcing=20
companies to accept liability isn't going to solve the problem, because=20
even with incentive to have perfectly secure software, companies will=20
be unable to deliver, due to the complexities of software development=20
and the lack of good tools and methodologies.

If that is the intent of Mr. Yoran's statement (which I'm sure it is,=20
as I'll get to in a moment), then he is dead-on. While there are=20
clearly easy things people can do that will help with the problem=20
(e.g., use any language other than C), the goal of building a system=20
without risk is more or less unachievable in practice. And the security=20
industry has done little to make it easy on developers, for whom=20
security can not ever be more than a part-time concern.

Not only have we, as an industry, not provided adequate tools to=20
support designing, building, and maintaining more secure systems, but=20
the "out of the box" security solutions we provide lend themselves to=20
misuse as well. For example, while Java is sometimes billed as a=20
"secure" language, I can tell you that we still tend to find one=20
significant security risk for every thousand lines of code (or so) in=20
Internet-enabled Java programs. Perhaps a better example is SSL/TLS,=20
where the libraries we provide developers encourage misuse. The mental=20
model developers need to use these libraries in a way that protects=20
against simple man-in-the-middle attacks is far more complex than the=20
model they tend to have (i.e., that SSL/TLS is a drop-in solution for=20
securing network traffic). As a result, the vast majority of=20
applications that deploy SSL/TLS get it wrong the first time, in a=20
major way.

Yes, there are software security problems that nobody should ever be=20
making, particularly the buffer overflow and its ilk. But, I'm sure=20
that you of all people should know how many things can go wrong in=20
networked applications (particularly when there are complex protocols=20
involved) and how obscure some of the faults in software systems can=20
be.  For example, there was a recent problem in your own Password Safe=20
that showed up despite a defensive design.

Moreover, I'm sure you're aware that design and analysis techniques for=20
software security are still in their infancy. I'm currently working on=20
putting together a consortium to develop better design methodologies=20
that better integrate with existing software engineering practices,=20
because there is nothing effective out there yet. And, while static=20
analysis technologies such as model checking are decades old, we've=20
only been applying them to security problems for a few years now. And=20
such technologies are still fairly far away from the point that they'll=20
be fairly complete and integrate adequately with the workflow of=20
finicky developers.

Even in a world with great design and analysis technologies, we're=20
going to have a hard time educating developers on the world of risk=20
around them to the point that social engineering attacks become totally=20
impractical. It's not unreasonable to say that we're far away from the=20
point where it would make financial sense to make software vendors=20
liable for security mistakes.

I do know Amit Yoran personally, and I know him fairly well. He is=20
extremely intelligent and understands the software security problem and=20
the limits of current technology. He understands this problem so well=20
that, before he accepted the job of Cybersecurity Tzar, he took a very=20
active interest in the affairs of our startup and our analysis=20
technology. As a result, I can say quite definitively that Amit not=20
only understands the software security problem far better than most=20
people do, he believes that it is important for the security industry=20
to pioneer a trail toward liability by providing better technologies=20
and methodologies.

I do see how you could have misinterpreted Amit's stance from the=20
ambiguity in that one quote. I am surprised, though, that you would=20
come to such a snap judgment based on it alone. Beyond the fact that=20
you've undoubtedly been misquoted to your detriment on at least one=20
occasion, a bit of diligence on Amit certainly would have turned up the=20
fact that he's actually quite clued in on this subject, and is not in=20
the same class as the typical snake-oil you expose on a monthly basis.



From: Mary Ann Davidson <[email protected]>
Subject: Amit Yoran

I am responding to a comment you made in the latest Cryptogram about a=20
quote Amit Yoran made (I have not read the original interview, so=20
please bear with me):

"'For example, should we hold software vendors accountable for the
security of their code or for flaws in their code?' Mr. Yoran asked in=20
an interview. 'In concept, that may make sense. But in practice, do=20
they have the capability, the tools to produce more secure code?'"

"The sheer idiocy of this quote amazes me.  Does he really think that=20
writing more secure code is too hard for companies to manage?  Does he=20
really think that companies are doing absolutely the best they possibly=20
can?"

I don't necessarily read that as indicating that it is too hard for=20
companies (with some caveats I will explain below) to write better=20
code. Referring to his comment about "the tools to produce more secure=20
code," I think it is true that the tools are lacking to help make it=20
easier to find nasty bugs in development.

This does not -- she said repeatedly -- excuse the overabundance of=20
avoidable, preventable security faults, but the lack of good code=20
scanning and QA tools does make it harder to do better, even if you=20
want to do better. I have seen development groups that "get" security,=20
have internalized it, who are all proud of themselves for checking=20
input conditions to prevent buffer overflows, but they only checked 20=20
out of 21 input conditions. One mistake still leads to a buffer=20
overflow, and is still really embarrassing and expensive to fix. If you=20
can automate more of these checks, it obviously will lead to better code.

Most of the code scanning/vulnerability assessment tools I see are=20
designed by consulting firms, which mean that they are generally not=20
designed to run against a huge code base every night, they don't work=20
on source code, they are not designed to be extensible, they have too=20
many false positives, and so on. Venture capitalists as a group are=20
often more interested in funding "Band-Aid" companies with outrageous=20
claims ("Our security product slices, dices, protects against all known=20
julienne fry attacks, and makes your teeth whiter, too!") than vaccine=20
companies ("scan code, find bugs, fix bugs before product ships so you=20
don't need Band-Aids, or need fewer of them"). You can make more money=20
on Band-Aids than on vaccines, which is probably one reason there are=20
so many snake-oil security products out there instead of a few really=20
good code scanning tools. Defense in depth is necessary, but we would=20
not need so much of it if we all made better products.

Clearly, corporate will to do a better job is a prerequisite, or nobody=20
would buy code-scanning tools, much less take the time to use them in=20
development.  Most of the security issues in industry come down to=20
"crummy code," and writing less crummy code is a matter of culture and=20
tools to do the job.  What amazes me is that almost every discussion=20
about this issue is prefaced with "...but we all know we can't build=20
perfect code." That does not mean we should stop trying, or that the=20
status quo is acceptable.

To answer your question (Does he really think that companies are doing=20
absolutely the best they possibly can?),  I've met Amit and talked to=20
him a couple of times. No, he is not letting industry off the hook and=20
no, I don't believe he thinks industry is doing everything they can.=20
I've never read his comments that way, at any rate.


** *** ***** ******* *********** *************


CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses,=20
insights, and commentaries on security: computer and otherwise.  Back=20
issues are available on <http://www.schneier.com/crypto-gram.html>.

To subscribe, visit <http://www.schneier.com/crypto-gram.html> or send=20
a blank message to [email protected].  To=20
unsubscribe, visit <http://www.schneier.com/crypto-gram-faq.html>.

Comments on CRYPTO-GRAM should be sent to=20
[email protected].  Permission to print comments is assumed=20
unless otherwise stated.  Comments may be edited for length and clarity.

Please feel free to forward CRYPTO-GRAM to colleagues and friends who=20
will find it valuable.  Permission is granted to reprint CRYPTO-GRAM,=20
as long as it is reprinted in its entirety.

CRYPTO-GRAM is written by Bruce Schneier.  Schneier is the author of=20
the best sellers "Beyond Fear," "Secrets and Lies," and "Applied=20
Cryptography,"  and an inventor of the Blowfish and Twofish=20
algorithms.  He is founder and CTO of Counterpane Internet Security=20
Inc., and is a member of the Advisory Board of the Electronic Privacy=20
Information Center (EPIC).  He is a frequent writer and lecturer on=20
security topics.  See <http://www.schneier.com>.

Counterpane Internet Security, Inc. is the world leader in Managed=20
Security Monitoring.  Counterpane's expert security analysts protect=20
networks for Fortune 1000 companies world-wide.  See=20
<http://www.counterpane.com>.

Copyright (c) 2004 by Bruce Schneier.