it's all about timing

[full-disclosure () lists netsys com (Steven M. Christey)]

> > = me
> = Jay D. Dyson

> I don't hold much empathy [for vendors who take more than 3 days to
> respond], quite honestly...especially since history shows that the
> greatest volume of attacks occur during holidays and off-hours (hence
> they shouldn't have skeleton crews during those times).
>
> Also for consideration is that every critical role in an
> organization should have a designated alternate who handles such reports
> when the canonical Big Cheese is off at the beach.

That may be an expectation of many in the security community, but I
don't think many vendors currently have this level of coverage.  And
for commercial vendors, a solid business case probably needs to be
made before they can commit to this type of response.  The customers
(or the "marketplace") may ultimately decide how quickly a vendor must
respond, but the security community is only a small portion (and
sometimes vendors say just that).  I don't think that the typical
customer thinks about disclosure issues, or at least it's not a factor
in purchasing decisions.  (And the only real data there seems to be on
disclosure opinions - the study by the Hurwitz Group - was based on a
survey of security professionals.)

> > The responsible disclosure draft allows for disclosure if the
> > researcher can't find the appropriate contact point, or if a human
> > does not respond (though it recommends involving a coordinator).
>
>       Myself and a couple of colleagues talked about an RFC of
> security () domain tld.  I was under the impression that such had been
> submitted by another party, but I haven't seen anything come to pass.

One concern with the "security" alias was that it was already
overloaded.  For example, it's already recommended in RFC2142 for
incident handling, and the alias could be in use for physical
security.  We proposed "secalert" because it's not overloaded, as
*nobody* is actually using it, which would mean that a vendor who uses
it, is probably interested in following community standards; but the
alias is not obvious, which is also a limitation.

One thing that's been suggested a number of times - in the feedback to
the RVDP draft, on this list, and elsewhere - is that vendors should
prominently display contact points for handling security issues.  If
that happens, then it wouldn't really matter which alias is used by a
particular vendor, and maybe standardizing on a single alias doesn't
become necessary.

> > > All bets are off if the vulnerability is discovered via a HoneyPot.
> > > Such a situation means that the exploit is in the wild and attackers
> > > already have full knowledge of attack methodology.
> >
> > There seems to be general agreement in this area, although the RDVP
> > draft did not address this (an oversight).
>
>       *nod*  Any chance that could be added, just to cover all the
> bases?

That's my intention, although it will likely be subjected to some form
of scrutiny and debate, just like almost every item in the original
draft ;-)

- Steve