Slow down the security patch cycle

[InfoSec News <isn () c4i org>]

http://www.computerworld.com/securitytopics/security/story/0,,92037,00.html

Opinion by Bill Addington
APRIL 08, 2004
COMPUTERWORLD

There are many myths surrounding computer network security that are
counterproductive to finding a true solution to the problem. One of
these is the belief that vendors should speed up the process of
producing and releasing patches for security vulnerabilities that have
been discovered by security researchers. Instead, we need a completely
different solution to the patch management problem, and part of the
solution involves slowing down, not speeding up, patch releases.

Slow them down? What about hackers taking advantage of the
vulnerability in the meantime? What about those "zero day" exploits?  
To answer this, we need to know how the researcher/patcher/exploiter
cycle really works and the motivations of each party in the cycle.  
This cycle is where researchers discover vulnerabilities, software
companies patch the vulnerabilities and hackers exploit the
vulnerabilities.

First, let's define a zero day exploit. An exploit is a method devised
to take advantage of a specific software vulnerability using a
software virus, Trojan horse or worm. When the exploit is done without
a virus, Trojan or worm, it's using an undocumented feature. The zero
day type of exploit is discovered, not as part of the security
research process, but when an active exploit is using a vulnerability
the software developer was previously unaware of. Many different
groups at that point rush to reverse-engineer the exploit to document
the vulnerability. Antivirus vendors compete to be first to announce a
method to detect and fix the exploit and the software vendor must
devise and release a patch immediately to combat the exploit.

By far the most common type of exploit is the buffer overflow, and
software vendors are spending millions of dollars to find and prevent
these types of vulnerabilities. These vulnerabilities still exist --
they are getting fewer in number, however, and finding them is now
much more difficult. Part of my consulting practice to software
vendors and their major customers is finding and reporting these types
of vulnerabilities. Where I used to be able to do the "find
vulnerabilities blindfolded with one arm tied behind my back" routine,
I now actually have to work to find them in major software products


[...]



_________________________________________
ISN mailing list
Sponsored by: OSVDB.org