[Secure-testing-team] Vulnerability impact on issues

Michael Gilbert michael.s.gilbert at gmail.com
Tue Nov 3 03:18:22 UTC 2009


On 11/1/09, Raphael Geissert wrote:
> Steffen Joeris wrote:
>> I am with Moritz here, if an issue is in serious need of fixing, it
>> usually gets an RT ticket in one of the security queues (and quite often
>> the first person that spots it and has the needed spare time fixes it).
>>
>
> I think the process regarding RT tickets should be made a bit more public,
> or at least documented. While this may work for stable and oldstable, it is
> leaving unstable behind as an issue in unstable may not be addressed as
> soon as in the stable releases.
>
> Cheers,

hi all,

i was thinking about this problem some more recently and came up with
the following conjecture: perhaps the key to making urgencies more
useful is to define them as time-based; rather than
qualification-based.

for example, the definitions could be plain and simple:

- high: an issue for which a fix optimally needs to be issued within
the next 24 hours (with a 36 hour maximum).  this category is
primarily reserved for issues that are known to be currently exploited
in the wild, weaknesses in cryptographic systems, and recently
disclosed vendor-sec issues.
- medium: an issue for which a fix optimally should be issued within
the next 14 days (with a 1 month maximum)
- low: an issue for which a fix optimally should be issued withn the
next 6 months (with a 1 year maximum).

obviously this categorization still remains very subjective, which is
unavoidable for any system due to the sheer ammount of unkowns related
to security issues. the key benefit is that these categories define
very clear and useful objectives/goals for the security team to meet,
rather than the current lack of any objectives, which would be very
useful.  note that the timeframes specified above are open for debate;
those were just my initial thoughts.

note that in this scheme, leaving an issue uncategorized would be
undesirable because there may be high and medium priority issues among
those that are undefined, so no one is aware that they should be
prioritizing their work to get those issues fixed in the desired
timeframes.

it may also be useful to set up metrics in the tracker to see how well
those objectives are being met down the road.

as an aside, it may also be useful to do more claiming of issues so we
know who is already working an issue.  this would be especially useful
if there are to be goals for getting the work done (so others know
when to step in when something is falling through the cracks).  i've
been thinking about working on the new xpdf issues for a while, but
i'm not sure if someone else is already on it or not.  there is some
documentation in the intro about claiming a section of issues in the
CVE list, but i've never seen that used.  maybe it would be more
straightforward/useful if the claims were on a per-package basis,
rather than full sections.  for example, i could claim an issue by
inserting my name into the parenthesis for the packages that i am
working on, e.g.:

   - xpdf <unfixed> (low; gilbert-guest)

mike



More information about the Secure-testing-team mailing list