[<prev] [next>] [day] [month] [year] [list]
Message-ID: <200208060048.UAA22437@linus.mitre.org>
From: coley at linus.mitre.org (Steven M. Christey)
Subject: Re: it\'s all about timing
choose.a.username@...hmail.com said:
>"security advisory"
>"vulnerability researchers"
>
>What are the definitions for these?
While "security advisory" implies a structured, comprehensive
vulnerability report, in general I mean any report of an issue with IT
security implications. SnoSoft's initial publication of the HP su
issue wasn't an advisory per se, but it was a vulnerability report.
I use "vulnerability researchers" more out of habit than anything; as
you say:
>For a vulnerability researcher, unless this is now a trade and a
>recognised job title with certification from some "school", who or
>what exactly is that? Joe Six-Pack installs a piece of software, he
>finds that pressing 1,2,3 on the key board at the same time deletes
>his hard drive. Thinks that's mighty unusual. Tells Joe 12-Pack, who
>tells him there is some mailing list you can send bugs to called
>bugtraq, so he posts it there. Knows nothing about anything. Certainly
>isn't a "vulnerability researcher" and certainly hasn't posted a
>"security advisory".
It's situations like these that caused us to try the term "reporter"
in the RVDP draft, as in "person/entity who reports the issue." But
as mentioned in another post, I'm leaning more towards "notifier."
>Doesn't know what he has and doesn't know what he is doing. Is the
>vendor going to come after them and sue them?
Hopefully not, but it appears that you and I disagree on whether
disclosure standards will help or hurt the situation.
>Then again, what is the definition of "security".
I think we'd need a whole new list for that ;-)
>Then on the other hand, you have some major vendors who go out of
>their way to discount what a some else finds as being nothing more
>than a "bug", that someone else follows the procedures, creates what
>they think is a ""security advisory" and nothing gets fixed.
The RVDP draft tries to recognize that there can be technical
disagreements, but short of recommending that a third party
coordinator to "negotiate," we don't really try to address the issue.
On the other hand, third parties such as w00w00 have proven effective
in the past.
As you have been describing in your posts, there are a number of
complex issues related to disclosure.
>A series of insurmountable hurdles or mitigating factors make it a bug
>and not a security matter at all. Hurdles like being enticed to visit
>websites on the internet or being enticed to click on links in
>emails. Someone else may take that publicised info and re-work it so
>that the hurdles are overcome, it may be a succession of 10
>individuals inputting each one step closer. Should all this be
>funnelled to the vendor when they've already dismissed the original as
>nothing more than bug?
If the vendor disagrees with the severity, then it seems reasonable
for the "notifier" to include the vendor's point of view in their
public "advisory." Then, as you point out, follow-on discussion may
reveal additional implications of the issue.
>Two bad examples but someone is going to have to define what a
>vulnerability is
That's not particularly easy. Everybody has different definitions,
partially due to different levels of "risk aversion."
>what a security advisory is and what vulnerability researchers are.
The current short definition of "reporter/notifier" is:
A [Reporter/Notifier] is the individual or organization that
informs (or attempts to inform) the Vendor of the vulnerability.
Note that the [Reporter/Notifier] may not have been the initial
discoverer of the problem.
The current draft doesn't include any definition of "security
advisory," so that will need to be addressed.
Thanks,
- Steve
Powered by blists - more mailing lists