lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <200601092321.21471.dhazelton@enter.net>
Date: Mon, 9 Jan 2006 23:21:15 -0500
From: "D. Hazelton" <dhazelton@...er.net>
To: bugtraq@...urityfocus.com, Gadi Evron <ge@...uxbox.org>
Subject: Re: industry standards - current status [was:  what we REALLY learned from WMF]

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

Download attachment "0xA6992F96300F159086FF28208F8280BB8B00C32A.asc" of type "application/pgp-keys" (1366 bytes)

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ