★ wanayoo — archive 1999 http://www.linuxsecurity.com/articles/cryptography_article-2864.htmlNouvelle recherche | Portail wanayoo
Advertise Here

   
Documentation
Security Sources
Forums
Firewalls
Host Security
Cryptography
Network Security
Intrusion Detection
Organizations/Events
Server Security
Vendors/Products
Projects
General
Privacy
Government
Hacks/Cracks
 
News: Cryptography 4/15/2001 11:33

Crypto-Gram April 2001

By Counterpane
Posted By: Dave Wreski
4/15/2001

Crypto-Gram is a free monthly newsletter providing summaries, analyses, insights, and commentaries on computer security and cryptography. This month, Bruce Schneier covers Natural Advantages of Defense, CSI's Computer Crime and Security Survey, Fake Microsoft Certificates, and a great news summary. Always worth reading.

CRYPTO-GRAM
                   April 15, 2001
  
                 by Bruce Schneier
                  Founder and CTO
         Counterpane Internet Security, Inc.
              schneier@counterpane.com
            
  
  
  A free monthly newsletter providing summaries, analyses, insights, and 
  commentaries on computer security and cryptography.
  
  Back issues are available at 
  .  To subscribe or 
  unsubscribe, see below.
  
  
  Copyright (c) 2001 by Counterpane Internet Security, Inc.
  
  
  ** *** ***** ******* *********** *************
  
  In this issue:
        Natural Advantages of Defense: What Military History
          Can Teach Network Security, Part 1
        A Correction: nCipher
        CSI's Computer Crime and Security Survey
        Crypto-Gram Reprints
        News
        Counterpane Internet Security News
        Fake Microsoft Certificates
        Comments from Readers
  
  
  ** *** ***** ******* *********** *************
  
             Natural Advantages of Defense:
  What Military History Can Teach Network Security, Part 1
  
  
  
  Military strategists call it "the position of the interior."  The defender 
  has to defend against every possible attack.  The attacker, on the other 
  hand, only has to choose one attack, and he can concentrate his forces on 
  that one attack.  This puts the attacker at a natural advantage.
  
  Despite this, in almost every sort of warfare the attacker is at a 
  disadvantage.  More people are required to attack a city (or castle, or 
  house, or foxhole) than are required to defend it.  The ratios change over 
  history -- the defense's enormous advantage in WW I trench warfare lessened 
  with the advent of the WW II blitzkrieg, for example -- but the basic truth 
  remains: all other things being equal, the military defender has a 
  considerable advantage over the attacker.
  
  This has never been true on the Internet.  There, the attacker has an 
  advantage.  He can choose when and how to attack.  He knows what particular 
  products the defender is using (or even if he doesn't, it usually is one of 
  a small handful of possibilities).  The defender is forced to constantly 
  upgrade his system to eliminate new vulnerabilities and watch every 
  possible attack, and he can still get whacked when an attacker tries 
  something new...or exploits a new weakness that can't easily be 
  patched.  The position of the interior is a difficult position indeed.
  
  A student of military history might be tempted to look at the Internet and 
  wonder: "What is it about warfare in the real world that aids the defender, 
  and can it apply to network security?"
  
  Good question.
  
  The defender's military advantage comes from two broad strengths: the 
  ability to quickly react to an attack, and the ability to control the 
  terrain.
  
  The first strength is probably the most important; a defender can more 
  quickly shift forces to resupply existing forces, shore up defense where it 
  is needed, and counterattack.  I've written extensively about how this 
  applies to computer security: how detection and response are critical, the 
  need for trained experts to quickly analyze and react to attacks, and the 
  importance of vigilance.  I've built Counterpane Internet Security's 
  Managed Security Monitoring service around these very principles, precisely 
  because it can dramatically shift the balance from attacker to defender.
  
  The defender's second strength also gives him a strong advantage.  He has 
  better knowledge of the terrain: where the good hiding places are, where 
  the mountain passes are, how to sneak through the caves.  This provides the 
  defender with an enormous advantage.  He can modify the terrain: building 
  castles or surface-to-air missile batteries, digging trenches or tunnels, 
  erecting guard towers or pillboxes.  And he can choose the terrain on which 
  to stand and defend: behind the stone wall, atop the hill, on the far side 
  of the bridge, in the dense jungle.  The defender can use terrain to his 
  maximum advantage; the attacker is stuck with whatever terrain he is forced 
  to traverse.
  
  On the Internet, this second advantage is one that network defenders seldom 
  take advantage of: knowledge of the network.  The network administrator 
  knows exactly how his network is built (or, at least, he should), what it 
  is supposed to do, and how it is supposed to do it.  Any attacker except a 
  knowledgeable insider has no choice but to stumble around, trying this and 
  that, trying to figure out what's where and who's connected to whom.  And 
  it's about time we exploited this advantage.
  
  Think about burglar alarms.  The reason they work is that the attacker 
  doesn't know they're there.  He might successfully bypass a door lock, or 
  sneak in through a second-story window, but he doesn't know that there is a 
  pressure plate under this particular rug, or an electric eye across this 
  particular doorway.  McGyver-like antics aside, any burglar wandering 
  through a well-alarmed building is guaranteed to trip something sooner or 
  later.
  
  Traditional computer security has been static: install a firewall, 
  configure a PKI, add access-control measures, and you're done.  Real 
  security is dynamic.  The defense has to be continuously vigilant, always 
  ready for the attack.  The defense has to be able to detect attacks 
  quickly, before serious damage is done.  And the defense has to be able to 
  respond to attacks effectively, repelling the attacker and restoring order.
  
  This kind of defense is possible in computer networks.  It starts with 
  effective sensors: firewalls, well-audited servers and routers, 
  intrusion-detection products, network burglar alarms.  But it also includes 
  people: trained security experts that can quickly separate the false alarms 
  from the real attacks, and who know how to respond.  This is security 
  through process.  This is security that recognizes that human intelligence 
  is vital for a strong defense, and that automatic software programs just 
  don't cut it.
  
  It's a military axiom that eventually a determined attacker can defeat any 
  static defense.  In World War II, the British flew out to engage the 
  Luftwaffe, in contrast to the French who waited to meet the Wehrmacht at 
  the Maginot Line.  The ability to react quickly to an attack, and intimate 
  knowledge of the terrain: these are the advantages the position of the 
  interior brings.  A good general knows how to take advantage of them, and 
  they're what we need to leverage effectively for computer security.
  
  The importance of detection and response in network security:
  
  
  Marcus Ranum has written and spoken about Internet burglar alarms.
  
  
  
  ** *** ***** ******* *********** *************
  
               A Correction: nCipher
  
  
  
  In the Crypto-Gram of January 2000, I wrote about a security vulnerability 
  publicized by nCipher.  I called this a publicity attack, meaning an attack 
  more designed to call publicity to the discoverer than the vulnerability 
  itself.  In any case, my write-up contained a factual error: I claimed that 
  nCipher distributed a tool that exploited this error, while in fact they 
  did not.  (I remember reading this somewhere, but I cannot remember 
  where.  And searching the various news archives, I can't find anyone else 
  who states this "fact.")
  
  nCipher was not pleased by this error.
  
  In the February Crypto-Gram I published a letter from nCipher correcting 
  this error.  I thought this was the end of it, and I moved on to other 
  things.  Unfortunately, in the January 2001 Crypto-Gram I published the URL 
  to the January 2000 article.  (This is what I do in the "Crypto-Gram 
  Reprints" section.)  This whole escapade never entered my mind; I didn't 
  think about the history of the article.
  
  Unfortunately, people read (or reread) the article without seeing the 
  correction.  And some of them contacted nCipher to complain.  And nCipher 
  (understandably) got all pissed off at me once again.
  
  So I am trying to correct the record.  nCipher claims that they did not 
  release a tool that exploits the vulnerability, and I believe them.  They 
  are a responsible company, and despite our disagreements as to the 
  motivations of their year-old discovery, they are an honorable and 
  upstanding company in the security community.
  
  For the record, nCipher has not threatened me or Counterpane with legal 
  action.  (I consider this admirable, which is why I mention it.)  They 
  contacted me personally.  They have a valid complaint, and I 
  apologize.  All you guys, stop bugging them.  And I hope that come next 
  January, I don't forget about this once again when it comes time to write 
  the "Crypto-Gram Reprints" section.
  
  The original essay:
  
  
  nCipher's letter:
  
  
  
  ** *** ***** ******* *********** *************
  
      CSI's Computer Crime and Security Survey
  
  
  
  For the past six years, the Computer Security Institute has conducted an 
  annual computer crime survey.  The results are not statistically meaningful 
  by any stretch of the imagination -- they're based on about 500 survey 
  responses each year -- but it is the most interesting data on real-world 
  computer and network security that we have.  And the numbers tell a 
  coherent story.  (I'm just going to talk about the 2001 numbers, but the 
  numbers for previous years track pretty well.)
  
  64% of respondents reported "unauthorized use of computer systems" in the 
  last year.  25% said that they had no such unauthorized uses, and 11% said 
  that they didn't know.  (I believe that those who reported no intrusion 
  actually don't know.)  The number of incidents was all over the map, and 
  the number of insider versus outsider incidents was roughly equal.  70% of 
  respondents report their Internet connection as a frequent point of attack 
  (this has been steadily rising over the six years), 18%  report remote 
  dial-in as a frequent point of attack (this has been declining), and 31% 
  report internal systems as a frequent point of attack (also declining).
  
  The types of attack range from telcom fraud to laptop theft to 
  sabotage.  40% experienced a system penetration, 36% a denial of service 
  attack.  26% reported theft of proprietary information, and 12% financial 
  fraud.  18% reported sabotage.  23% had their Web sites hacked (another 27% 
  didn't know), and over half of those had their Web sites hacked ten or more 
  times.  (90% of the Web site hacks were just vandalism, but 13% included 
  theft of transaction information.)
  
  What's interesting is that all of these attacks occurred despite the wide 
  deployment of security technologies: 95% have firewalls, 61% an IDS, 90% 
  access control of some sort, 42% digital IDs, etc.  Clearly the 
  technologies are not working sufficiently well.
  
  The financial consequences are scary.  Only 196 respondents would quantify 
  their losses, which totaled $378M.  From under 200 companies!  In one 
  year!  This is a big deal.
  
  More people are reporting these incidents to the police: 36% this 
  year.  Those who didn't report were concerned about negative publicity 
  (90%) and competitors using the incident to their advantage (70%).
  
  This data is not statistically rigorous, and should be viewed as suspect 
  for several reasons.  First, it's based on the database of information 
  security professionals that the CSI has (3900 people), self-selected by the 
  14% who bothered to respond.  (The people responding are probably more 
  knowledgeable than the average sysadmin, and the companies they work for 
  more aware of the threats.  Certainly there are some large companies 
  represented here.)  Second, the data is not necessarily accurate, but is 
  only the best recollections of the respondents.  And third, most hacks 
  still go unnoticed; the data only represents what the respondents actually 
  noticed.
  
  Even so, the trends are unnerving.  It's clearly a dangerous world, and has 
  been for years.  It's not getting better, even given the widespread 
  deployment of computer security technologies.  And it's costing American 
  businesses billions, easily.
  
  The survey (you have to give them your info, and they will send you a paper 
  copy):
  http://www.gocsi.com/prelea_000321.htm
  
  
  ** *** ***** ******* *********** *************
  
               Crypto-Gram Reprints
  
  
  Microsoft Active Setup "Backdoor"
  
  
  UCITA:
  
  
  Cryptography: The Importance of Not Being Different:
  
  
  Threats Against Smart Cards:
  
  
  Attacking Certificates with Computer Viruses:
  
  
  
  ** *** ***** ******* *********** *************
  
                        News
  
  
  
  Government warning about ways to bypass an IDS:
  
  
  Good articles on building secure Linux:
  
  
  
  This is the FBI affidavit about Robert Hanssen that discusses the letter 
  the FBI decrypted:
  
  
  One of the secrets Hanssen told the Russians was that the U.S. dug a tunnel 
  under the Soviet embassy in Washington to eavesdrop on their 
  communications.  From the March 19th Newsweek article on the subject: 
  "laser beams could pick up vibrations from the keystrokes of Soviet 
  ciphering machines -- helping to decode their signals."  This is an example 
  of what I call "side-channel cryptanalysis," using information other than 
  the plaintext and ciphertext to cryptanalyze traffic.  I have long believed 
  it to be the primary way cryptanalysis is done in the intelligence community.
  Side Channel Cryptanalysis:
  
  
  I've already written about the Eastern European hackers stealing credit 
  card numbers, the FBI's warning, and the fact that the thieves were using 
  documented and fixable security vulnerabilities.  Well, the Center for 
  Internet Security has released a tool that scans your network to see if it 
  is vulnerable to the specific attacks used by these groups.  On the one 
  hand, this is kind of dorky: all the vulnerabilities are well known, and 
  any scanner is likely to pick them up...and more.  But on the other hand, 
  this is an excellent idea.  The tool works, it's free, and addresses a 
  problem in the news.  If people download and run this tool, it will help 
  increase their security.  Kudos to the CIS for making this available.
  
  
  Businesses are losing more to Internet crime, even though they're using 
  more security technology.
  
  
  
  Write your own Visual Basic worm and infect the Net!
  
  Remember kids, this is "for educational use only."
  
  Remember Microsoft's claim that the security features added to the next 
  versions of Office and Windows would make it extremely difficult to 
  pirate?  Well, the security lasted negative one months.
  
  
  Son of CPRM:
  
  
  Impressive identity thefts:
  
  
  The revised 802.11 security standard is more public:
  
  But more flaws in its security have been found:
  
  
  Security and 802.11 wireless:
  
  
  Interesting article on the NSA:
  
  
  A vulnerability was found in the OpenPGP standard.  If an attacker can 
  modify the victim's encrypted private key file, he can intercept a signed 
  message and then figure out the victim's signing key.  (Basically, if the 
  attacker replaces the public key parameters with weak ones, the next 
  signature exposes the private key.)  This is a problem with the data 
  format, and not with the cryptographic algorithms.  I don't think it's a 
  major problem, since someone who can access the victim's hard drive is more 
  likely to simply install a keyboard sniffer.  But it is a flaw, and shows 
  how hard it is to get everything right.  Excellent cryptanalysis work here.
  Announcement:
  
  News reports:
  
  
  
  
  The research paper:
  
  
  More dire warnings from the FBI:
  
  
  Web bug reports.  See who's using Web bugs.
  
  
  Microsoft Outlook virus.  (Note: this is a joke.)
  
  
  This is a clever idea to help stop cell phone theft:
  
  
  
  Yet another Windows feature that will be riddled with 
  insecurities.  Windows XP will have something called "shared desktop" that 
  will allow users to manipulate their PC over the Internet.  Read the last 
  paragraph of this article.  Does anyone think this will be secure?
  
  
  Microsoft redefines the word "secure."  Remember when "secure" meant "not 
  leaking private or secret data against the owner's wishes"?  Microsoft 
  thinks it means "unable to duplicate copyrighted works that are nonetheless 
  within the Fair Use doctrine."
  
  
  Another Microsoft disaster in the making: an operating system that 
  automatically updates itself without the user's knowledge or consent:
  
  
  Trying to make a Napster-proof CD:
  
  
  "War Driving": Driving around with an 802.11-equipped PC, looking for 
  unsecured networks to access:
  
  
   From a 1996 NSA document:  "This instruction incorporates a philosophy of 
  'risk management' in lieu of the 'risk avoidance' philosophy employed in 
  the previous document."  And: "The emphasis is placed on 'detection' of 
  attempted penetration in lieu of 'prevention' of penetration."  Good for them.
  
  
  First-ever cross-platform virus: affects Windows and Linux:
  
  
  SEC may regulate Internet security:
  
  
  An April Fools RFC about firewalls:
  
  
  Another Internet Explorer hole.  Normally, I wouldn't bother.  But this 
  quote is telling:  "Security 'is an ongoing issue with Internet Explorer 
  because it is such a complicated software that interoperates with many 
  other applications that it is too difficult to figure out all of these 
  vulnerabilities,' said Richard Smith, chief privacy officer at the 
  Denver-based nonprofit group the Privacy Foundation."
  
  
  Companies who sell security software exacerbate the problem, as they try to 
  sell software solutions to people problems.  (I've been saying this for a 
  while.)
  
  
  Here's a hacking tool designed to sneak past IDSs:
  
  
  Good article on the reality vs. hype of cyberterrorism:
  
  
  I've already written about the dangers of software auto-update 
  features.  We now have a mass-market product instance of this.  One day 
  ReplayTV updated itself to disable a valuable feature:
  
  
  
  ** *** ***** ******* *********** *************
  
  Counterpane Internet Security News
  
  
  
  Counterpane announced more customers:
  
  
  Cisco supports Counterpane's Managed Security Monitoring:
  
  
  Schneier will be speaking at the CATO Institute, in Washington DC, on April 
  19th:
  
  
  Schneier will be speaking at BlackHat Asia, in Hong Kong (4/23) and 
  Singapore (4/26):
  
  
  Schneier will be speaking at the Investment Company Institute quarterly 
  meeting in Washington DC on May 2:
  
  
  Schneier will be speaking at the BankLink annual conference in New York on 
  May 4:
  
  
  Schneier will be speaking at the Los Angeles ISSA Conference on May 10:
  
  
  Schneier will be speaking at the New York ISSA Conference on May 17:
  
  
  Schneier spoke on NPR about the difficulty of copy protection on personal 
  computers.  You can listen to the audio of his talk on the web.
  http://www.npr.org/ramfiles/atc/20010305.atc.12.rmm
  
  
  ** *** ***** ******* *********** *************
  
            Fake Microsoft Certificates
  
  
  
  Ah, the tribulations of PKI.  Apparently someone impersonated Microsoft to 
  VeriSign, and got a couple of certificates in Microsoft's name.  Oops.
  
  This is a big deal.  Microsoft has been pushing trusted code as a cure-all 
  for Internet viruses and other rogue programs.  The idea would be that a 
  user could only allow signed code from trusted sources to run on his or her 
  computer.  But if you can't trust the certificates, this all falls apart.
  
  There are a lot of details that are unclear.  Some news reports claim that 
  the certificates will expire in a year, others claim that they will be good 
  forever.  (Expired certificates are all over the Web; almost nobody pays 
  attention.)  VeriSign claims that they discovered the fraud almost 
  immediately, and that there has been no other fraud.  While I agree that 
  their audit processes caught the problem in this case -- and I applaud 
  their going public with it so quickly -- I just don't believe they can be 
  sure more clever fraud remains unnoticed.
  
  What's most interesting is that there is no way to revoke the certificates 
  (Windows has no CRL features), even though there have been rogue 
  certificates before.  Revocation is critical to making PKI work, and it's 
  one of the major holes in most consumer PKI applications.
  
  Microsoft has tried to paint this problem as 1) not a security 
  vulnerability, and 2) all VeriSign's fault anyway.  But if it's not a 
  security vulnerability, why are they issuing all these security patches for 
  Internet Explorer?
  
  News reports:
  
  
  
  Typical Microsoft evasiveness:
  
  Especially interesting is the number of patches Microsoft needed to issue 
  to ensure that the revoked keys are actually revoked.
  
  Ten Risks of PKI:
  
  
  
  ** *** ***** ******* *********** *************
  
              Comments from Readers
  
  
  
  From: Bruce Peaslee 
  Subject: Security Patches
  
  I used to religiously -- and automatically -- apply all security patches 
  for Microsoft Office, but no more!  One of the more recent patches to 
  Outlook 2000 made it impossible to receive executable attachments.  This 
  includes, of course, Microsoft Office files themselves.  Thus I could not 
  e-mail myself an Excel file I was working on at work.  I had to uninstall 
  then reinstall the whole system.  I'm not sure what the moral is here, but 
  even if you do make the attempt, you can get unexpected and unsatisfactory 
  results.
  
  
  From: "Mike O'Connor" 
  Subject: Security Patches
  
  Vendors often release patches that do more than address a discrete security 
  issue.  They'll incorporate other bug fixes and performance enhancements, 
  which potentially introduce new bugs, slowdowns, quirks, downtime, 
  integration issues, and security downfalls.  There's often a sense that the 
  vendor knows what's best for you, even though they may have an imperfect 
  understanding of how you use their stuff at a higher level.  Installing the 
  new patch in the name of security may not be the smartest thing to do if 
  the new "features" of the patch act as a DOS attack or compromise system 
  integrity.
  
  In most cases, the guts of the system environments that need patching are 
  unknown quantities to administrators.  They don't have the time, charter, 
  expertise, access to source and build environments, etc. to dig into what 
  makes their system environments tick at a low level.  Admins gain 
  confidence in what they've built from their black boxes by looking at 
  high-level performance over time.  When asked to apply the latest security 
  patches, what they see (when not swearing under their breath) is this 
  unknown amount of entropy potentially kicking them.  "Simply" applying 
  patches takes LOTS of time when factoring in testing.
  
  With all that in mind, I think we need to preach the following:
  
  a) Vendors need to get it in their consciousness and processes that getting 
  security fixes into their products should be separate from getting other 
  stuff in their products.  Admins need to get fixes from their vendors which 
  consist of EXACTLY the same as what they run today plus the one lone 
  security fix.
  
  b) Admins need to be aware of what patches are out there and articulate 
  clearly when they don't run with them.  A security patch should be treated 
  as a potentially actionable system event every bit as much as a "disk is 
  full" message.  (That's where Counterpane can fit in, letting customers 
  know and tracking how they respond.)
  
  Otherwise, the situation with patches will never get better.
  
  
  From: "Dunn, Andrew (Reading)" 
  Subject: Insurance
  
  I don't normally respond to newsletters, but your article on insurance 
  really is very wide of the mark.  I could write a treatise on why it is so 
  badly misconceived, but I don't have that much time to spare.  Briefly your 
  fundamental error is to believe that insurance provides restitution for 
  loss.  It does not.
  
  Insurance provides financial compensation.  Whatever the type of insurance, 
  the insuree obtains the insurance for events which he does not want to 
  happen.  In some, but only a very few cases, those events relate to a 
  financial loss, such as, if I have my wallet stolen and I only have cash in 
  my wallet, and no other documents or credit cards.  In most cases, the loss 
  is not primarily financial.  If I have accident insurance, I receive cash 
  if I lose an arm, but it does not replace the arm.
  
  It's exactly the same in business.  Businesses do not exist purely to 
  generate cash, although that's an important, and necessary objective.  All 
  businesses have other objectives than simply making the maximum profit in 
  the next quarter, regardless of what happens after that.  Different 
  businesses have different objectives and core values.  Some aim for 
  long-term growth, some aim for market leadership, some aim for technology 
  leadership.
  
  If a business goes into liquidation because of a security hack, then 
  financial compensation does not replace the business.  In the UK, we have a 
  classical example of why compensation does not make up for loss.
  
  In the foot and mouth crisis, many farmers are having their entire 
  livestock destroyed after many years of building it up.  This is a terrible 
  time for farmers despite the fact that they will receive financial 
  compensation.  We are starting to hear the first cases of farmers 
  committing suicide.  There is no greater loss than that.  And insurance 
  does not have any play in this at all.
  
  
  From: "Daniel A. Graifer" 
  Subject: Insurance
  
  As an economist, let me comment on this:
   >The real world doesn't work this way.  Businesses achieve
   >security through insurance.  They take the risks they are
   >not willing to accept themselves, bundle them up, and pay
   >someone else to make them go away.  If a warehouse is
   >insured properly, the owner really doesn't care if it
   >burns down or not.  If he does care, he's underinsured.
  
  In general with insurance, this is called the moral hazard problem.  The 
  insurer figures that (in your example) the warehouse owner is the best 
  placed to be sure that fire safety regulations and common sense preventions 
  are carried out.  That's why insurance policies have deductibles: to 
  encourage responsible action by preventing 100% coverage of the risk 
  leading to irresponsible behavior.
  
  This is also related to the other big bugaboo of insurance:  "adverse 
  selection":  Insurance buyers have better knowledge of their risk 
  characteristics than the insurers, leading higher risk clients to 
  over-insure (because it's cheap relative to the risks) and low risk clients 
  to under-insure.  That's why non-elective group insurance is cheaper than 
  individual policies in any risk category.
  
  
  From: "John J. Adelsberger III" 
  Subject: Insurance
  
  You have written many times about how mistaken you were when you used to 
  say that mathematics could solve security problems.  This is good, because 
  you're right; mathematics alone will not solve any problem which is no 
  purely mathematical in nature.
  
  However, the basic mistake you made was not assuming that math could 
  provide security.  The basic mistake was the assumption that magic bullets 
  really exist, which solve hard problems neatly, cleanly, and without any 
  side effects.
  
  You might find it interesting to read your own article on insurance over 
  again in light of this fact.  You like to say "repeat after me."  Well, 
  repeat after me: insurance is not a magic bullet.  Magic bullets do not exist.
  
  You wrote this:
   >When I talk about this future at conferences, a common
   >objection I hear is that premium calculation is
   >impossible.  Again, this is a technical mentality
   >talking.  Sure, insurance companies like well-understood
   >risk profiles and carefully calculated premiums.  But
   >they also insure satellite launches and the palate of
   >wine critic Robert Parker.
  
  Here's how I can rewrite it to be a little less propagandistic:  "When I 
  talk about this future at conferences, a common objection I hear is that it 
  is impossible to calculate rationally correct premiums free from subjective 
  whimsy.  The answer is simple: premiums will be calculated 
  irrationally.  Favoritism, corporate inertia, reputation, and an old boys 
  network will be as important as quality.  The ability to pass meaningless 
  certifications with inflated prices and get face time with dough-faced 
  meeting monkeys will be what counts."
  
  Doesn't sound quite so rosy this time, does it?  And yet, you know that it 
  is the same thing you said: do you really believe there's a rational way to 
  value the palate of a wine critic up front?!
  
  The irony here is that you think this will somehow dramatically improve the 
  quality of security products.  In fact, it will do precisely the opposite: 
  it will make it "ok" to produce, sell, buy, and use lousy products.  Even 
  experts will agree, in time.  Do you know why most homes are so easy to 
  break into?  Because there's no economic benefit to securing them; just 
  getting insurance is so much cheaper!
  
  Since you mention premium manipulation as economic incentive to do the 
  right thing, here's something you'll never get an insurance guy to admit: 
  The real reason they toy with premiums for "good" customers is purely 
  marketing.  It gets them more insurance sales revenue per policy over the 
  long run than they'd otherwise have.  They don't really think they can 
  predict the odds of your house being broken into, much less the change in 
  those odds from installing deadbolts and shatter alarms.  They just pretend 
  to do that because otherwise the government would nail them for illegal 
  price discrimination, product tying, and so on.  They try, of course, to 
  have a rough idea of how many payouts they're going to have to make in a 
  year, but that's hardly at the level of one claim; that's just based on 
  gross statistics over the last x years in y area.
  
  Insurance?  Yes.  It is coming.  Panacea?  Well, if you want to make a bet 
  on that, let me know.  I'm always willing to supplement my income.
  
  
  From: "Fred Renner" 
  Subject: Insurance
  
  In the mid-80s I was trying to sell various electronic security-enhancing 
  technologies to companies that were being threatened or damaged 
  substantially by new vulnerabilities in both physical and virtual 
  worlds.  In most of the commercial (versus government) enterprises the 
  response was leaning, just as you described, toward insurance as the 
  answer.  So I approached some insurance companies with the idea that they 
  could reduce damage claims by encouraging or rewarding use of better 
  security practices and technologies.  There was even historical precedent 
  in the insurance companies collectively "inventing" private fire 
  departments.  What I learned during that brief and unrewarding sales effort 
  was informative as well as discouraging, at least for me.
  
  The insurance industry is a deeply multilayered structure, with the first 
  layer of companies selling risk protection to consuming organizations or 
  individuals and buying risk protection from Layer #2 insurance companies, 
  which may spread it among a consortium of their peers or buy protection 
  policies from Layer #3.  Pricing of all these exchanges is based on 
  industry-wide experiences.  Consequently, the first-layer companies have no 
  immediate incentive to encourage the use of loss-reducing 
  technologies.  Layers #2 and above are too far removed from the consuming 
  organizations to care about or influence their behavior.
  
  The net result is a structure that effectively discourages using practices 
  to inhibit the criminal population and actually subsidizes them by "taxing" 
  the whole economy.  In evolutionary terms, a steady food supply encourages 
  population growth and we are certainly seeing a growth in virtual 
  vermin.  It may be an efficient solution in bean-counting terms but it has 
  always galled me.  Wish I had an answer.
  
  
  From: /dev/null 
  Subject: Attrition.org's Web site Defacement Data
  
  Hi, Bruce.  In the recent Cryptogram, you referenced us:
  
   >Security patches aren't being applied:
   >
   >Best quote:  "Failing to responsibly patch computers led
   >to 99 percent of the 5,823 Web site defacements last
   >year, up 56 percent from the 3,746 Web sites defaced in
   >1999, according to security group Attrition.org."  I'm
   >not sure how they know, but is scary nonetheless.
  
  Shockingly enough, ZDNet put words in our mouth.  The stats on defacements 
  are ours; that's what we do.  We mirror defacements and provide statistical 
  information about them.  We do not, however, speculate as to how or why 
  sites were defaced.  Certainly, it's usually quite obvious to us what tools 
  and scripts defacers are using (i.e., last summer there was an astounding 
  spike in Red Hat Linux defacements, and most of those boxes defaced had 
  port 21 open...it's an easy guess that they were hit with wu-ftpd's 
  vulnerability); however, unless we have concrete evidence of some kind, we 
  don't speculate to the press on what vulnerability was used.  At most, a 
  general statement could be made that the vast majority of defacements occur 
  due to known vulnerabilities that have not been patched or otherwise 
  defended against.  We know of defacements that were compromised by weak 
  passwords, social engineering, or other unusual approaches, but by far most 
  of them are simply a matter of kids using available tools to exploit 
  well-known holes for which patches are available.
  
  
  From: Greg Guerin 
  Subject: Codesigning
  
  In your February "Comments from Readers" section, Phillip Hallam-Baker 
   wrote:
  
   >If the hackers circulated the private key to any great
   >extent, the compromise would soon be known.
  
  What if hundreds or thousands of different hackers are doing this?  What if 
  an autonomous software agent (or hundreds of them) does it dozens of times 
  a day?  How many humans are actually monitoring this kind of thing at 
  VeriSign (which actually issues and revokes the Authenticode code-signing 
  certificates, not Microsoft)?  How long would it take for them to find out, 
  especially if the worm is not wreaking immediate havoc, but only sneaking 
  into place for a later or subtler exploit?
  
   >The certificate would be revoked and would not be
   >accepted by the Authenticode signing service for future
   >code signing requests.
  
  This implies that there is a centralized Authenticode service that hands 
  out single-use permissions to sign each individual piece of code; i.e., 
  centralized approval of each signature created.  I could be wrong, and I'd 
  happily plead ignorance, but I don't think Authenticode works that way.  An 
  Authenticode signing key is just a VeriSign Class 3 code-signing key, and 
  any entity that has the private key and the cert can create the 
  Authenticode signature.
  
   >Software that had already been signed would still pose
   >a risk, but this could be controlled through warnings in
   >the press.
  
  Ah, yes, "warnings in the press," whose efficacy is so conveniently 
  illustrated in "The Security Patch Treadmill."
  
  Another illustration is the recent incident of two Authenticode 
  certificates erroneously issued by VeriSign to someone posing as "Microsoft 
  Corporation."  These certificates assert that the key-holder is "Microsoft 
  Corporation," and someone paid real money ($400/year each) to obtain 
  them.  VeriSign's fraud monitoring eventually figured out the mistake, but 
  it took them six weeks after issuing the certificates.  Even so, no 
  Microsoft software is capable of automatically obtaining the Certificate 
  Revocation List (CRL) listing those two bogus certs, because there's no 
  revocation infrastructure.  Oops.  Instead, Microsoft has to issue a patch 
  that will use a local CRL plus enable CRL-checking in all their 
  Authenticode-using programs.  So once again, it comes down to "warnings in 
  the press."  Will Microsoft do the same thing every time a certificate 
  needs to be revoked before its stated expiry date?
  
   >In the future it is likely that a higher level of
   >security will be possible in enterprise
   >configurations.  Ideally each software installation
   >would be referred to a central service for prior
   >approval.
  
  Something like a centralized service that can approve or decline the 
  execution of every executable on every known client machine in the 
  enterprise.  Something like, say, SecureEXE:
     
     
  
  Something like this is essentially powerless over buffer overrun exploits, 
  scripting or macro viruses, interpreted executables like Java, or directly 
  interpreted languages like Python, Perl, etc.  In short, something like 
  this would only work on roughly half the worms/viruses out there.  The 
  likely effect of this central service would be little more than to change 
  the balance of how new worms and viruses are written.
  
  
  From: Steven Bass 
  Subject: 802.11 Standard Security
  
  I think your analysis of the 802.11 flaw is flawed.  Yes, an analysis by a 
  security expert would have probably caught this error and produced a better 
  solution.  But this was not a closed process.
  
  The American standard processes, whether by IEEE, ANSI, ASTM, or one of the 
  many industry fora, are essentially volunteer processes.  As an attendee at 
  a number of ANSI and IEEE standards meetings, I can say that while they are 
  difficult, often highly political, and frequently incomprehensible to new 
  attendees, the people there are generally open to contributions from anyone 
  interested in contributing.  My guess is that the people who implemented 
  the WEP security were well-meaning people not versed in security; they did 
  the best they could to develop a solution within the constraints they 
  faced.  At the time, they were limited to 40-bit crypto for export.  They 
  may have had proprietary solutions in the field which needed to remain 
  compatible.  So they took their best shot and drew up something.
  
  While the standards are under development, many working documents are 
  freely available (for example the 802.11 documents are at 
  ), so any 
  cryptographer with interest could follow the process by reading the 
  documents and provide feedback at no cost.
  
  When released, they do cost money, as that is a primary funding mechanism 
  for IEEE and ANSI.  But this is a red herring; once the standard is 
  released, it is largely too late to change things.
  
  While the standard committees are open to anyone, they are largely driven 
  by corporate interests.  Corporation have both money and a vested interest 
  in the outcome.  This has worked pretty well in the past, by forcing 
  competing manufacturers, network system designers, and large corporate 
  users to build consensus.
  
  The real question behind your comment is what is the best way to create 
  standards.  As a volunteer process, if there are no voices representing a 
  particular viewpoint, it isn't heard.
  
  Even if all standards in development were posted for free on the Web, it 
  wouldn't help much.  802.11 was a many-year effort, at times a real mess 
  trying to merge pre-existing solutions into a standard.  For many years it 
  was considered to be a failure that would never be released.  For a long 
  time after it was released many thought it doomed to niche status by one 
  thing or another (Hiperlan, Bluetooth, or something else).
  
  And this was just one of dozens (if not hundreds) of standards that have 
  been developed or are being developed for networking systems (and don't 
  forget busses, disk drive protocols, content rights systems, computer 
  architectures, Web protocols, etc.).  Since it is impossible to know which 
  will win in the marketplace, and once one does it is too late to easily fix 
  the security problems, that means security experts need to be part of EVERY 
  potentially relevant standard effort.
  
  Don't blame the openness of the process, or the cost of the 
  standard.  They're not the problem here.  There are simply too many 
  different standards under development, and not enough people with the 
  knowledge, interest, or time to analyze them all.
  
  
  From: Michael Rabin 
  Subject: Ding-Rabin Provably Unbreakable Encryption
  
  This is a brief response to "Harvard's 'Uncrackable' Crypto."  Many experts 
  who heard lectures and read the paper were enthusiastic. Some of the less 
  informed reactions fit well into the following mold.  William Cruikshank, 
  writing in 1790 about human physiology said (not that hyper encryption is 
  as important as Harvey's work):  When Harvey discovered the circulation of 
  the blood, his opponents first attempted to prove that he was mistaken; but 
  finding this ground untenable, they then asserted that it was known long 
  before...; when this failed they once more shifted their ground and said 
  the discovery was of no use.
  
  Harvard Univ. or its public relations department had nothing to do with the 
  publicity for hyper-encryption.
  
  Maurer proposed the bounded storage model.  However, he does not have a 
  practical method which is provably unbreakable.  He has suggested putting 
  us in touch with people to commercialize our work, but we are not following 
  this now.
  
  That encryption is vitally important is evidenced by the hundreds of 
  millions spent on encryption technology and the billions spent on 
  code-breaking.  Once discovered, the provably secure encryption will be 
  used sooner rather than later.
  
  The proposal to store the bit stream by bouncing it between satellites is 
  infeasible because the mirroring method allows storage of about a second's 
  worth of bit transmission, while the adversary must store several weeks or 
  even years worth of the stream.
  
  Full answers to various questions is to be found in the site pointed to in 
  my and Yan Zong Ding's web pages at Harvard DEAS.
  
  
  ** *** ***** ******* *********** *************
  
  CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, 
  insights, and commentaries on computer security and cryptography.
  
  To subscribe, visit  or send a 
  blank message to crypto-gram-subscribe@chaparraltree.com.  To unsubscribe, 
  visit .  Back issues are 
  available on .
  
  Please feel free to forward CRYPTO-GRAM to colleagues and friends who will 
  find it valuable.  Permission is granted to reprint CRYPTO-GRAM, as long as 
  it is reprinted in its entirety.
  
  CRYPTO-GRAM is written by Bruce Schneier.  Schneier is founder and CTO of 
  Counterpane Internet Security Inc., the author of _Secrets and Lies_ and 
  _Applied Cryptography_, and an inventor of the Blowfish, Twofish, and 
  Yarrow algorithms.  He served on the board of the International Association 
  for Cryptologic Research, EPIC, and VTW.  He is a frequent writer and 
  lecturer on computer security and cryptography.
  
  Counterpane Internet Security, Inc. is a venture-funded company bringing 
  innovative managed security solutions to the enterprise.
  
  
  
  Copyright (c) 2001 by Counterpane Internet Security, Inc.
  
Web Bugs Track Users, Extract Information
Apr 16

802.11 and swiss cheese
Apr 16

Hack attacks: Who's to blame?
Apr 16

Securing Java Code: Part 1
Apr 16

Linux Security Week - April 16th 2001
Apr 16

Crypto-Gram April 2001
Apr 15

Make SSH do more
Apr 15

Contact Us | Legal Notice | About Our Site
© Guardian Digital, Inc., 2000