Re: standards status in the industry - opinion?

[Matthew Murphy <mattmurphy () kc rr com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Gadi Evron wrote:
> Hi guys. I just replied to a flame-bait on bugtraq explaining (hopefully
> better) what I was trying to say. I figure a discussion on this can be
> cool.
>
> Please read and let me know what you think.
>
>     Gadi.
>
> 5 points in this post, all directed as a personal attack. I learned to
> only answer one out of every flame-baits, so I will concentrate on the
> ideas behind the post instead.
>
> 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.
>
> Now, the point I am trying to make is not MS-specific, but rather about
> our standards in the industry.

Most people are trying to tie you into a catch-22 of sorts.  They act as
though you expect to see 9-14 day patch timelines all the time.  While
I'd love to see them do that, it isn't practical in most cases.

People are trying to sitting on that and say "Well, don't expect them to
fix every bug in 9 days!".

I agree with that, but I think it misses the point.  The fact is that
180-200 days go by before Microsoft issues patches for serious bugs.
Sometimes more.  That's flat-out unacceptable.

180 days should be an absolute maximum, IMHO, and not a matter of
routine.  No security bug should *ever*, under any circumstances, be
delayed for that length of time without a significant architectural
obstacle.  While MSFT is getting better, I will not be satisfied until
they can get patches out the door in sixty to ninety days, and do it
regularly.

There's never been any doubt that their current patch timelines are
utterly unacceptable.  The point you make that I think people miss, is
that their response to WMF proves they can do it.  They just think that
it's inconvenient and therefore won't step up the pace on issues unless
their hand is forced.

They're betting that the community will just roll over and play their
game, and so far, they've been betting right.  It's about time that we
started taking them to task on this, and quit letting their investment
in security technology quiet the bad press.  Truth is, they don't have
the human element down at *ALL* as yet.  And while there've been
positive steps, they're primarily focused on handling emergency
situations.  What the problem seems to be, is that Microsoft doesn't
treat privately-reported bugs with any degree of urgency.

> 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.
>
> 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.
>
> Same goes as to patches.

And, if I get the message you're trying to give us, let's not set our
standards low anywhere else, either.  I'd love to see more effective
heuristic patterning in IDS/AV as well.  That was one of the major
battles with this WMF exploit was dealing with signatures that:

1) were too reactive
2) undercovered (sometimes, knowingly, to avoid FPs)

> In the Oracle case I was in complete agreement with Dave, but my opinion
> was that the medium was wrong, and in some cases - the medium is the
> message. That's something we'd have to disagree on.

Unfortunately, when companies' processes are as broken as those of
Oracle, you really don't have a better medium.  My problem with most
commercial security response frameworks is the general inability for
researchers who are generally concerned about the handling of a
vulnerability to bring supervisory involvement into the process.

In my time working with MSRC, for instance, the supervisors have been
these mythical, unreachable figureheads that I never hear from in my
everyday work.  As a result, I'm not able to have any input on the
process that gets anywhere constructive.  If I propose an idea, the
Microserf reading the MSRC mailbox will say "Hmm... sounds interesting",
maybe reread it a few times, and then move on.  My ideas, and more
importantly, my problems with the process fall squarely on the shoulders
of whomever I'm working with day-to-day.  The level of researcher input
and interaction with supervisors is nil.

> 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.

Oracle is certainly a worst-case, as far as commercial-ware is
concerned.  Plenty of people will point that out, and plenty of people
will point to how much MS has improved in recent years.  Why isn't
anyone asking the tough questions to MSRC?  Such as "If you can patch a
zero-day in nine days, why do you need 180+ days to patch *EVERY*
vulnerability of similar severity that you're made aware of?"

Is it, perhaps, because we can answer our questions ourselves?  Is it,
perhaps, because MS doesn't really need those 180-odd days, and is
instead just victimizing the community and its customers by leeching
from our free labor?  I think so.

> 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.

Absolutely.  If not 9 days, or even 14, something more moderate than
Redmond's current tendency to spend eternity on fixes would be a very
welcome improvement.  I'd be happy with 60-90 days in comparison to the
black hole that is Microsoft's response to security holes today.

> 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.
>
> We are like a toad. Throw us into boiling water and we would jump right
> out, screaming. Slowly raise the temperature of the water and we might
> not even notice it.
>
> Then suddenly.. we see bright light, and that is that standards in the
> industry are too low. That is my opinion -- I may be wrong, but if you
> wish to dispute it, I suggest you at least try rather than baiting for a
> flame war.

I'm not much of an expert on AV, IDS, IPS, etc., but I *CAN* say that
Microsoft's patch timeframes are driven by not only a low standard but a
flat-out lack of standards.  Most members of the community would let
them get away with damn near whatever timeframe they please.  That's the
fact of today's world.  For those of you who've been exceptions to that
(you know who you are) good job.

While I don't have a problem with how Microsoft did this patch (in fact,
I think they did a fantastic job), it confirms what I've believed to be
true all along: that Microsoft's patch timeframe is a matter of
convenience, not concern for compatibility.  It is based upon a standard
that is far too low, particularly as the incentive for malicious
individuals to exploit its products continues to grow.  Can anyone say
botnet?

- --
"Social Darwinism: Try to make something idiot-proof,
nature will provide you with a better idiot."

                                -- Michael Holstein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDvwXdfp4vUrVETTgRA/m3AKCB9S+8UCLSXDESNkwQgg1HEHQAMgCeMI/M
LTTKI9lOPLmRTtUyy4+pfhE=
=Np6q
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.