New encryption technology closes WLAN security loopholes

Rick Smith at Secure Computing rick_smith at securecomputing.com
Mon Oct 1 11:38:30 EDT 2001


At 03:01 PM 9/30/2001, Dan Geer wrote:

>  >  Or in other words, the first requirement for perimeter security is
>  >  a perimeter.
>
>Wireless networks have no interior.

What you have is a perimeter that shrinks to that of the individual 
devices. And you have to slice and dice your security policy so it 
considers types of risk incurred by penetrating different types of 
perimeters, instead of simply saying one set of things is 'trusted' and the 
rest 'untrusted.'

In the world of crypto, you want to treat different perimeters differently 
simply because some risks are more profound -- the perimeter that protects 
long lived keying material is more important than the one to protect 
session keys, etc.

>  ...the apps are where the action is now.

I'd argue that this has always been true. The problem has always been that 
designers often ignore security issues and rely on features of existing 
products or infrastructure to provide the right protection. The results are 
often heavy handed and tend to leave gaps that are hard to monitor and/or 
patch.

The only way an application will get built-in security is if the design 
team includes someone who has looked at the security threats and developed 
application design requirements to address them. This doesn't seem to be a 
well-established process, partly because the requirements vary from one 
application to the next.

Financial systems represent one of the few application areas that have a 
set of reasonably well known security objectives, and they even have well 
known mechanisms to address them: the traditions of separation of duty and 
of double entry bookkeeping. These help detect unintentional errors as well 
as some types of intentional fraud.

>  Within my firm's experience, fully 70% of the fatal
>application vulnerabilities seen in the field are design flaws
>so there is certainly work to be done.

And I'll bet you can trace the flaws back to an absence of design 
requirements to address the associated security risks. This is depressing 
when a requirement might be blindingly obvious, like individual accountability.


Rick.
smith at securecomputing.com          roseville, minnesota
"Authentication" coming in October http://www.visi.com/crypto/




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com




More information about the cryptography mailing list