Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217

[Lars Kurth <lars.kurth@xxxxxxx>]

> > /  1. Purpose of the process/
> >
> > /  The first point is that we think the security vulnerability process/
> > /  document should have an explanation of what its goals are.  This would/
> > /  have greatly assisted us when making some of the more difficult/
> > /  decisions./
> The security vulnerability process document should most definitely
> encapsulate both explicit guidance and broad tenets that can be used
> to make tough calls. I think that these should be explicitly called
> out in front matter as an evolutionary part of the process. Tenets
> should always be open to being refined or redefined as Xen.org
> projects grow and usage shifts.
I wanted to dive a little bit into the purpose of the process as the
discussion will otherwise get stuck on detail. Also into the actors
in a security vulnerability and their interest.

1.1: The Xen.org Security team, whose task is to administer the process
and act as referee if needed: the process should provide clarity and
ensure that the team can be seen as referee. The process needs to be
clear enough to avoid a chance that members of the team are accused of
being partial.

1.2: Discoverer of the vulnerability: The process must provide an
incentive for the discover to report the issue to the project. If we
get the process wrong, the consequence will be that vulnerabilities
will not be reported to us. That would be detrimental to all
stake-holders as it will increase days-of-risk for everybody else.
E.g. if the embargo period is too long. Not sure what other factors
motivate a discoverer.

1.3: Developers within the project, who will be task to find a fix
as quickly as possible.

1.4: 3rd parties that may need to be contacted in order to develop a
fix to understand the issue and advise the security team (in the case
of CVE-2012-0217 hardware vendors).

1.5: Developers of downstream projects/distros consuming Xen and
distributing it (FOSS or commercial), who will apply the fix to
their project/distro.

1.6: Other direct consumers of Xen (e.g. service providers). Their
main goal of the process would be to reduce days-of-risk for
themselves. The issue being that deploying a fix can take a long time.
Another issue is that providing a fix before somebody else is a
competitive advantage.

1.7: Indirect consumers of Xen. With all the same motivations than
direct consumers.

A couple of observations:
1) The further you get down the list, the more people are involved,
the greater the risk that information will leak.
2) Groups 1.1 - 1.4 necessarily need to be involved to create a fix,
as otherwise there won't be a fix for the other groups.
3) Groups 1.6 - 1.7 are directly impacted by days-of-risk
4) Groups 1.1, 1.3 & 1.5 are impacted insofar that the reputation
of their organisation may be damaged if the situation is not handled
well.
 
Of course the ultimate goal of the process should be to minimize
days-of-risk for everyone. To do this, the process has to balance the
following factors to reduce days-of-risk

A) Provide incentive for vulnerabilities to be reported to Xen.org
security team in the first place
B) Time it takes to develop a fix
C) Time it takes downstream projects/distros to apply it
D) Time it takes to deploy fixes for consumers (1.6 & 1.7)
E) Reduce the possibility of a leak (keep pre-disclosure list small)
F) Avoid the perception that members of the pre-disclosure list have
an unfair advantage
 
Looking at the existing pre-disclosure list shows that it contains
parties from all groups. This opens Xen.org up to criticism that some
members of the pre-disclosure have an uncertain advantage, which has
already been highlighted earlier in this discussion.

To be honest, I don't really see a way to satisfy all needs:
- Restrict membership of disclosure lists to stake-holders 1.1, 1.2,
  1.3 and 1.5 with members of 1.4 drawn in as needed and full public
  disclosure afterwards as to who was consulted.
- Of course it may be desirable to get advice from members of groups
  1.6 and 1.7. Or is it? If it is, a different approach may be to have
  a merit rather than size based selection criteria for members of 1.6
  and 1.7 (e.g. something along the lines of "contributions" to the
  community, but that would need to be measurable - or even some sort
  of elections). But it is hard to see how this would work in practice.
  Of course such an would have the advantage that a member of that group
  that used mbership to gain an unfair advantage over others could be
  removed from the pre-disclosure list.
- Another possible approach may be a two-stage pre-disclosure
  - Stage 1: Groups 1.1, 1.2, 1.3 and 1.5 with 1.4 as needed
  - Stage 2: Groups 1.6 and 1.7 (with a relatively weak membership
    criterion such as being a service provider - but then how does
    this differ from being public and who would administer?)
- Another option may be to delegate more difficult issues on
  principle to an independent organisation such as OCERT.

Best Regards
Lars
P.S.: I just wanted to make clear that these are my personal views and reflect
in no way any position of Xen.org or my employer.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel