Re: [Xen-devel] Possible improvement to Xen Security Response Process

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 23 Jan 2017, at 11:30, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
>>>> On 20.01.17 at 20:21, <ijackson@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>> James Bulpin writes ("Re: [Xen-devel] Possible improvement to Xen Security 
>> Response Process"):
>>> , and the issue is considered to be of significant urgency due
>>> to its severity, then the fourth Tuesday in the month should be
>>> considered so long as this allows for a 14 day pre-disclosure
>>> period" (or something like that).
>> 
>> I agree with Jan that this fuzziness is undesirable.  Also, more
>> severe vulnerabilities are both more urgent to fix, and also have
>> worse impact if released before people are ready, so severity is the
>> wrong measure.  If there is any kind of measure that is relevant it is
>> difficulty.
>> 
>> I'm writing here mostly with my personal hat, but my security team hat
>> really dislikes ambiguity like this.  It leads to unclear
>> decisionmaking and side discussions.
>> 
>> I would like the policy to specify a clear cutoff.  Jan, are you
>> comfortable with a "default" of between 2 and 4 weeks' embargo,
>> depending on the timing of the discovery etc. ?  Personally I think a
>> 4 week maximum seems rather long, but with a 2 week cadence that can't
>> be reduced without also shortening the 2 week minimum.  The range 2-4
>> weeks seems like a plausible compromise.
> 
> Well, 4 weeks seems pretty much to me too. Especially during calm
> periods I wonder if it wasn't better to limit the embargo period by
> simply promising to have a minimum distance of two weeks between
> public disclosures.

I think what everyone agreed to was to always pre-disclose when
ready. So the proposal would only affect the public disclosure
date, unless
- we are talking about a 0-day
- the discoverer expresses other wishes

To summarise the thread, it seems to me that having a predictable 
schedule and batching is seen as a valuable thing. The sticky point 
is the timing.

1) 2 weeks may be too short - the point that was raised that
this could require reducing the embargo period. Another way of 
looking at this would be to always publish XSAs in the next batch, 
if a minimum of 14 days of pre-disclosure could not be guaranteed.
This would essentially increase the worst case scenario to 4 weeks.

2) 3 weeks wasn't discussed and may be a good compromise, although
it would not be as intuitive as every even/odd week or once a month.

3) 4 weeks or once a month may be too long - extending the 
embargo period to up to 6-7 weeks in the worst case scenario

4) I also know that Matthew keeps statistics and graphs on past XSAs, 
so he should be able to relatively easily model and share the impact 
of a fixed model public disclosure date based on the last few years
of data. He could create a model for each scenario, highlighting
- number of XSA's per date
- actual latency
Maybe that could inform the discussion.

The other thing is that to some degree we are speculating as to what
may or may not be acceptable to our user-base. If [4] does not
settle the question, maybe a survey would?

The other question we have not considered is longer term: how
does LivePatching fit into the picture? There may be a tension 
between those that already have and those that don't have
such capability. 

A concern was raised about the testing and validation of batched 
changes. That looks like a valid concern and may need some more
discussion. I think at this stage it is not clear how much of a 
real problem this would be. [4] would probably help settle this 
question.

Maybe Matthew could help pull [4] together?

Best Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel