[42155] in bugtraq
Re: industry standards - current status [was: what we REALLY learned from WMF]
daemon@ATHENA.MIT.EDU (D. Hazelton)
Fri Jan 13 02:37:58 2006
From: "D. Hazelton" <dhazelton@enter.net>
To: bugtraq@securityfocus.com, Gadi Evron <ge@linuxbox.org>
Date: Mon, 9 Jan 2006 23:21:15 -0500
In-Reply-To: <43BEF5B6.9020306@linuxbox.org>
MIME-Version: 1.0
Content-Type: multipart/signed;
boundary="nextPart14224173.DgErngoNKe";
protocol="application/pgp-signature";
micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200601092321.21471.dhazelton@enter.net>
--nextPart14224173.DgErngoNKe
Content-Type: multipart/mixed;
boundary="Boundary-01=_8YzwD+DKCA9Ogq5"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--Boundary-01=_8YzwD+DKCA9Ogq5
Content-Type: text/plain;
charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I track this list to keep abreast of new bugs so I can try to take pro-acti=
ve=20
steps with the systems I run. In this case I've been ignoring this thread=20
until now... About what I've seen of the five points in discussion here -=20
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 w=
ith=20
critical patches in this manner a great deal of the time. The same goes for=
=20
all other major software companies, as well - in concurrence with your note=
=20
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.
=46alse positives should be handled in a quiet manner by vendors, IMHO. If =
they=20
do otherwise it causes a drop in quality of information available. Not that=
=20
this is a feasable solution re: most software companies. In a number of=20
cases, as demonstrated by events at MS during the developement cycle of=20
Windows 95, there is a large amount of legacy code that isn't clearly=20
documented or isn't documented at all. For applications that are recent and=
=20
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 trut=
h=20
about my belief that software companies should actively work to eliminate=20
those false positives to increase the quality of information available to t=
he=20
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 practic=
e.
Agreed. Critical security patches should have a shortened development and=20
testing cycle so they can reach the end-users as fast as possible. Although=
,=20
in light of my (somewhat limited) knowledge of corporate practices and=20
policies this might take work to get any number of the larger companies to=
=20
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 inconsistenci=
es=20
noted in a clear manner and I happen to agree with it all. If the software=
=20
industry can change it's paradigms for inherent security - trying to make t=
he=20
products harder to exploit from the design phase on - and change it's=20
handling of extremely critical security patches (Like MS did about the rece=
nt=20
WMF vuln) then the work of I[DP]S (to borrow your shorthand) professionals=
=20
will be made that much easier.
However I am not going to even dream that the industry will change in this=
=20
manner. That is something that I don't see happening unless the community a=
nd=20
various governmental agencies (in the US and other nations) begin to place=
=20
_serious_ and _continued_ pressure on the industry to change in that manner=
=2E=20
Since a large number of people across the globe would have to agree for tha=
t=20
to happen I cannot consider it a real possibility.=20
Although, I must say, if MS does for future critical security patches what =
it=20
did for the WMF patch, the rest of the industry may follow MicroSoft. Thoug=
h=20
I like to bash MS as much as the next Linux user, they do have a huge segme=
nt=20
of the market for Operating Systems and business software. A large enough=20
segment that a change they make does have a chance of spreading through the=
=20
rest of the industry.
D. Hazelton
--Boundary-01=_8YzwD+DKCA9Ogq5
Content-Type: application/pgp-keys;
name="OpenPGP key 0xA6992F96300F159086FF28208F8280BB8B00C32A"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=0xA6992F96300F159086FF28208F8280BB8B00C32A.asc
-----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-----
--Boundary-01=_8YzwD+DKCA9Ogq5--
--nextPart14224173.DgErngoNKe
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQBDwzZBj4KAu4sAwyoRAsTKAJsEsH/H1wZXWcgNqJPM+1OtS+MA6ACcCHcF
UmxXwz0StqBjXXXHToJxwxE=
=MuMF
-----END PGP SIGNATURE-----
--nextPart14224173.DgErngoNKe--
