BugTraq
what we REALLY learned from WMF Jan 05 2006 09:53PM
Gadi Evron (ge linuxbox org) (1 replies)
Re: what we REALLY learned from WMF Jan 06 2006 05:33AM
Thor (Hammer of God) (thor hammerofgod com) (1 replies)
industry standards - current status [was: what we REALLY learned from WMF] Jan 06 2006 10:56PM
Gadi Evron (ge linuxbox org) (1 replies)
Re: industry standards - current status [was: what we REALLY learned from WMF] Jan 10 2006 04:21AM
D. Hazelton (dhazelton enter net)
I track this list to keep abreast of new bugs so I can try to take pro-active
steps with the systems I run. In this case I've been ignoring this thread
until now... About what I've seen of the five points in discussion here -
certainly. It does seem to be flame-bait.

Now onto the content...

On Friday 06 January 2006 17:56, Gadi Evron wrote:
<snip>
> Microsoft did nothing wrong, in fact, they did great. Microsoft is an
> easy choice in this case because even though each case varies, they
> showed a capability here to deal with issues much faster than usual.

Agreed. MS is a company that has the resources and should be able to deal with
critical patches in this manner a great deal of the time. The same goes for
all other major software companies, as well - in concurrence with your note
below.

> Now, the point I am trying to make is not MS-specific, but rather about
> our standards in the industry.
>
> As an example, take false positives. A HUGE problem I[DP]S experts try
> and deal with every day, invest a lot of time in, and yet can't solve...
> therefore we got used in the industry to a level of false positives.
>
> Same goes to vulnerability scanners.. false positives appear as a way of
> nature.

False positives should be handled in a quiet manner by vendors, IMHO. If they
do otherwise it causes a drop in quality of information available. Not that
this is a feasable solution re: most software companies. In a number of
cases, as demonstrated by events at MS during the developement cycle of
Windows 95, there is a large amount of legacy code that isn't clearly
documented or isn't documented at all. For applications that are recent and
not prey to the ravages of poorly understood legacy code it can work.

> And yet, some vendors are different than others. In I[DP]S as well as
> vulnerability scanning. With some vendors, they invest less in features
> and more in eliminating false positives. They treat them as full-blown
> bugs rather than "something to live with". It works -- at least better
> than with others.

Ah, I see. Makes my previous statement a bit pointless, other than the truth
about my belief that software companies should actively work to eliminate
those false positives to increase the quality of information available to the
community.

<snip>

> In this case though, it is once again about standards. Microsoft shows
> Oracle is not alone, although they achieved amazing progress, especially
> in the last couple of years.
>
> If a patch can be put through full testing and released within days when
> it is taken seriously enough and resources are invested - no matter for
> what reason, I see no reason myself that this can't become common practice.

Agreed. Critical security patches should have a shortened development and
testing cycle so they can reach the end-users as fast as possible. Although,
in light of my (somewhat limited) knowledge of corporate practices and
policies this might take work to get any number of the larger companies to
understand.

> We should be practical in our demands, but if in practice this can be
> done in days, surely vendors can step it up a notch on critical issues.
> Microsoft runs on most of the computers on this planet, therefore they
> are to be treated different for better and for worse. A year+ of waiting
> for a patch while people might be exploited is unacceptable according to
> standards we should be upholding now that we know what is possible.

I do agree. See above section.

<snip>

In conclusion all I can say is that you addressed the seeming inconsistencies
noted in a clear manner and I happen to agree with it all. If the software
industry can change it's paradigms for inherent security - trying to make the
products harder to exploit from the design phase on - and change it's
handling of extremely critical security patches (Like MS did about the recent
WMF vuln) then the work of I[DP]S (to borrow your shorthand) professionals
will be made that much easier.

However I am not going to even dream that the industry will change in this
manner. That is something that I don't see happening unless the community and
various governmental agencies (in the US and other nations) begin to place
_serious_ and _continued_ pressure on the industry to change in that manner.
Since a large number of people across the globe would have to agree for that
to happen I cannot consider it a real possibility.

Although, I must say, if MS does for future critical security patches what it
did for the WMF patch, the rest of the industry may follow MicroSoft. Though
I like to bash MS as much as the next Linux user, they do have a huge segment
of the market for Operating Systems and business software. A large enough
segment that a change they make does have a chance of spreading through the
rest of the industry.

D. Hazelton
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.1 (GNU/Linux)

mQGiBEJS3C0RBADeLmOaFYR40Pd/n86pPD10DYJIiSuEEJJAovJI/E3kjYgKnom0
CmwPa9oEXf4B3FMVcqB0ksKrhA8ECVsNRwO91+LObFczyc59XBgYDScn9h9t+lu4
IZTObcR1SnQ/I+YdeJpd12ZcuLAnQ3EGl9+7bBOJgr4JcwM6Idixtg92kwCg4vhj
97BpUqPSk6cwD4LMRoqzABcEAJPZdEpYDwrXiy5aQx8ax+CbdfJX+XhxVcOrqzoI
8TS7yZPcE1rszCANpCb6xg7TReWyIOu+FQvfzLg5e7Cl2XtVC66RDgdlTBy/pjnX
fxIOIW5Hl+cVaWLBJ2tdAOIiyGPrKC/uTyY/N+4iQTsQK2l/yxc3fOgEN0g9AY9a
GSkHBACmX6awLcrdnxY0p2J/OmRtT4oOWcbq5TUchM9SzPLLIatGZEs7jUal9OYo
ZzmRPjElgM4koF7TTB+71FTUaqVGd0smJVKfJ1nVp6nefxOI6MH/v8/4j7Bvtb1Y
Ypkrxt+R8WWUI1L19yEDp55rvzqIkkLtmJZP/QJg2e7zxTYYi7Q5RGFuaWVsIFIu
IEhhemVsdG9uIChUaGUgU2hhZG93V29sZikgPGRoYXplbHRvbkBlbnRlci5uZXQ+
iF4EExECAB4FAkJS3C0CGwMGCwkIBwMCAxUCAwMWAgECHgECF4AACgkQj4KAu4sA
wyoRwwCeN+PEM8jpxxpxiG4dGyXNwTZBtNkAoKAtdOgeK66+zPEtJFanUeFe6lRX
uQENBEJS3DoQBACfejnq7GSJ7g8nL669pXDVFFrabOaiIC4sH0FgqbK+Oewm4h77
Ir5QL9SsHWvYSBYxnCODvR7zHv8HefWgJ4duC66b8PCXY/qcmxhRhYtdEssx/ncm
BhNXlPPvsyPT/e7PdZkDv7dJuVtVJrLVVeSniz+3KBIIYb395B+yhzjPLwAEDQP9
HFlaX9Duyg8c+RFhqStVrIluy7ZTg8pGjF2KLPsCmcSVzVLLhplF1M6Fs1CSgwRe
OCDRWPFohcaSxPIwIdlS0h2HOnWziPVpzh4HWylbtC6cZYg7dpgaDlJA00ikUlyj
6/bxwNwBuVoNSegIe0mN+xAIsvXM2TLuY1fFYcmeRxmISQQYEQIACQUCQlLcOgIb
DAAKCRCPgoC7iwDDKsoRAJwKJETliGVgcCSTMd7sq/WMOe9VAgCgxq4MRqWBvPWY
fPs99FjiIC8asFc=
=vwF/
-----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDwzZBj4KAu4sAwyoRAsTKAJsEsH/H1wZXWcgNqJPM+1OtS+MA6ACcCHcF
UmxXwz0StqBjXXXHToJxwxE=
=MuMF
-----END PGP SIGNATURE-----

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus