Possible improvement to Xen Security Response Process

Possible improvement to Xen Security Response Process

[Matthew Allen]

According to https://xenbits.xen.org/xsa/ we are in the middle of 
4 consecutive Tuesdays of security announcements: XSA-19[1-8]
on Nov. 22, XSA-201 Nov. 29, XSA-199 Dec. 6 and XSA-200 Dec. 13.
The present security policy does not encourage batching of XSAs and
I would like us to consider refining the policy to permit this.

The present approach of frequent security updates causes significant 
disruption to users.  Many organisations test updates before deploying
in production; because security updates are so important this displaces 
other work at short notice and doing so repeatedly is a significant
impact to users of Xen.  Updating the policy to encourage the batching
of updates would reduce the load of using Xen.

From a security purist point of view, any delay in publication could 
increase the possibility of vulnerabilities being exploited in the
wild.  However, given the significant frequency of publication of XSAs,
I’d suggest that users failing to keep up with the publication rate
is presently a much greater security risk.

If XSAs were to be batched, we should also consider if batch updates 
should be encouraged to be on pre-defined dates.  The present
unpredictability makes it unnecessarily more difficult for users of
Xen to plan their lives.  For example, our present process causes 
organisations with few administrators to choose between cancelling
holidays or not patching.

Obviously, some issues are discussed in public before the security 
impact is realised (such as XSA-201); equally, the right to set 
a disclosure date (if any) rests with the discoverer.  However,
my experience of other software (which may not be typical) has been
that discoverers are usually happy to go along with any reasonable
proposed date given in the same way that discoverers of XSAs are
usually happy to conform to our present policy.

If this seems a good idea, then I’ll post a concrete proposal but 
I’d like to get general feedback first.



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

Re: Possible improvement to Xen Security Response Process

[Jan Beulich]

>>> On 05.12.16 at 15:17, <matthew.allen@citrix.com> wrote:
> From a security purist point of view, any delay in publication could 
> increase the possibility of vulnerabilities being exploited in the
> wild.  However, given the significant frequency of publication of XSAs,
> I’d suggest that users failing to keep up with the publication rate
> is presently a much greater security risk.
> 
> If XSAs were to be batched, we should also consider if batch updates 
> should be encouraged to be on pre-defined dates.  The present
> unpredictability makes it unnecessarily more difficult for users of
> Xen to plan their lives.  For example, our present process causes 
> organisations with few administrators to choose between cancelling
> holidays or not patching.
> 
> Obviously, some issues are discussed in public before the security 
> impact is realised (such as XSA-201); equally, the right to set 
> a disclosure date (if any) rests with the discoverer.  However,
> my experience of other software (which may not be typical) has been
> that discoverers are usually happy to go along with any reasonable
> proposed date given in the same way that discoverers of XSAs are
> usually happy to conform to our present policy.
> 
> If this seems a good idea, then I’ll post a concrete proposal but 
> I’d like to get general feedback first.

I think very much here depends on the concrete aspects of the
proposal (timing, room for exceptions, etc). From just a general
pov, I can see advantages and disadvantages to both, just like
you've indicated yourself already. Also it shouldn't be left out of
consideration that for less severe vulnerabilities consuming
parties could decide for themselves whether to delay patching
(and hence leverage batching); I'm not convinced it would be a
good idea to require the XenProject Security Team to take this
decision in all cases.

Jan

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

Re: Possible improvement to Xen Security Response Process

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2266 bytes --]

On Mon, 5 Dec 2016, Jan Beulich wrote:
> >>> On 05.12.16 at 15:17, <matthew.allen@citrix.com> wrote:
> > From a security purist point of view, any delay in publication could 
> > increase the possibility of vulnerabilities being exploited in the
> > wild.  However, given the significant frequency of publication of XSAs,
> > I’d suggest that users failing to keep up with the publication rate
> > is presently a much greater security risk.
> > 
> > If XSAs were to be batched, we should also consider if batch updates 
> > should be encouraged to be on pre-defined dates.  The present
> > unpredictability makes it unnecessarily more difficult for users of
> > Xen to plan their lives.  For example, our present process causes 
> > organisations with few administrators to choose between cancelling
> > holidays or not patching.
> > 
> > Obviously, some issues are discussed in public before the security 
> > impact is realised (such as XSA-201); equally, the right to set 
> > a disclosure date (if any) rests with the discoverer.  However,
> > my experience of other software (which may not be typical) has been
> > that discoverers are usually happy to go along with any reasonable
> > proposed date given in the same way that discoverers of XSAs are
> > usually happy to conform to our present policy.
> > 
> > If this seems a good idea, then I’ll post a concrete proposal but 
> > I’d like to get general feedback first.
> 
> I think very much here depends on the concrete aspects of the
> proposal (timing, room for exceptions, etc). From just a general
> pov, I can see advantages and disadvantages to both, just like
> you've indicated yourself already. Also it shouldn't be left out of
> consideration that for less severe vulnerabilities consuming
> parties could decide for themselves whether to delay patching
> (and hence leverage batching); I'm not convinced it would be a
> good idea to require the XenProject Security Team to take this
> decision in all cases.

Given that the disclosure date is always chosen by the discoverer, the
only thing the security team can do is to suggest. It could make sense
to have a policy to pick the date the team should propose to the
discoverer, but at the end of the day, it is always, entirely, up to
her.

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: Possible improvement to Xen Security Response Process

[Matthew Allen]

On Mon, 2016-12-05 at 11:24 -0800, Stefano Stabellini wrote:
> On Mon, 5 Dec 2016, Jan Beulich wrote:
> > >>> On 05.12.16 at 15:17, <matthew.allen@citrix.com> wrote:
...
> > > Obviously, some issues are discussed in public before the security 
> > > impact is realised (such as XSA-201); equally, the right to set 
> > > a disclosure date (if any) rests with the discoverer.  However,
> > > my experience of other software (which may not be typical) has been
> > > that discoverers are usually happy to go along with any reasonable
> > > proposed date given in the same way that discoverers of XSAs are
> > > usually happy to conform to our present policy.
> > > 
> > > If this seems a good idea, then I’ll post a concrete proposal but 
> > > I’d like to get general feedback first.
> > 
> > I think very much here depends on the concrete aspects of the
> > proposal (timing, room for exceptions, etc). From just a general
> > pov, I can see advantages and disadvantages to both, just like
> > you've indicated yourself already. Also it shouldn't be left out of
> > consideration that for less severe vulnerabilities consuming
> > parties could decide for themselves whether to delay patching
> > (and hence leverage batching); I'm not convinced it would be a
> > good idea to require the XenProject Security Team to take this
> > decision in all cases.
> 
> Given that the disclosure date is always chosen by the discoverer, the
> only thing the security team can do is to suggest. It could make sense
> to have a policy to pick the date the team should propose to the
> discoverer, but at the end of the day, it is always, entirely, up to
> her.

I agree; I'm suggesting changes to the dates that the security team
would propose to a discoverer.  It's clearly entirely up to the
discoverer whether they accept the proposal or decide on a different
date (and they are, of course, under no obligation to contact the
security team in advance at all).
It does seem that discoverers are usually kind enough to contact the
security team and consent to the dates suggested by the present policy;
we should respect that kindness by making best use of the flexibility
offered as well as ensuring timely release.



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

Re: Possible improvement to Xen Security Response Process

[Ian Jackson]

Matthew Allen writes ("Re: [Xen-devel] Possible improvement to Xen Security Response Process"):
> I agree; I'm suggesting changes to the dates that the security team
> would propose to a discoverer.

Right.

Personally I think that batching would be valuable, if it does not
lead to either inordinate delay or precipitate publication.  Of course
opinions about what "inordinate" or "precipitate" mean are likely to
produce some disagreements...

Matthew's suggestion of having fixed dates is a possible way forward
but it might also lead to avoidable delays.


I have an alternative concrete suggestion:

 Unless there are good reasons to diverge, our suggestions to
 discoverer(s) will be based on the following criteria, in order of
 precedence:
 1. Avoiding disclosure on Fridays, weekends, or on or immediately
    before widely respected public holidays.
 2. Minimising the number of distinct publication dates 
    within each 14 day period.
 3. Making the preparation period for each advisory as close,
    on a log scale, to 14 days as possible.
 (The preparation period for an advisory is the period between
 predisclosure and publication.)

Essentially this means that if predisclosure of a second batch occurs
in the first 5 days of a 14 day preparation period, the existing date
will be reused; on or after the 6th day, a new date, beyond, will be
suggested.  So the minimum preparation period is 9 days (9/14 = ie,
1.55x too short), and the maximum is 22 days (22/14 = 1.57x too long).
(Figures slightly fudged due to day-granuarity rounding error.)

That's a suggested compromise between those who will want to do
batching by making the timescales shorter and those who want to make
them longer.  (Using a log scale avoids the problem that a linear
scale would mean that the error factor would be ~2x short but only ~1.5x
long.)


Bunfight, anyone ?


Ian.
(Responding with a personal opinion, and hence from a personal
 email address.  I haven't discussed this with my management at
 Citrix.)

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

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

Re: Possible improvement to Xen Security Response Process

[Matthew Allen]

On Wed, 2016-12-07 at 16:23 +0000, Ian Jackson wrote:
> ...
> I have an alternative concrete suggestion:
> 
>  Unless there are good reasons to diverge, our suggestions to
>  discoverer(s) will be based on the following criteria, in order of
>  precedence:
>  1. Avoiding disclosure on Fridays, weekends, or on or immediately
>     before widely respected public holidays.
>  2. Minimising the number of distinct publication dates 
>     within each 14 day period.
>  3. Making the preparation period for each advisory as close,
>     on a log scale, to 14 days as possible.
>  (The preparation period for an advisory is the period between
>  predisclosure and publication.)
> ...
> Bunfight, anyone ?
> 
> 
> Ian.
> (Responding with a personal opinion, and hence from a personal
>  email address.  I haven't discussed this with my management at
>  Citrix.)
> 

I'll join in the bunfight with a stronger proposal (noting in passing
that according to https://xenbits.xen.org/xsa/ we are now expecting 5
consecutive weeks of XSA announcements):
1) Where practical, XSA public disclosures will be batched and announced
once per month.
2) The calendar of disclosure dates will be published well in advance
and will avoid Fridays, weekends, or dates on or immediately before
widely respected public holidays.
3) Issues will normally have at least 14 days pre-disclosure; this means
that an issue discovered immediately prior to a scheduled publication
date will normally not be disclosed until the next publication date.

Clearly there will be times when this can't be done; I am also aware
that discoverers always have the final say.  But both of those points
apply to the current policy as well.

I know that this would be a significant change.  However, the present
frequent and unpredictable nature of disclosures consumes a lot of time
that would otherwise be better spent on contributing to and improving
Xen.

Matthew




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

Re: Possible improvement to Xen Security Response Process

[Anthony Liguori]

On Mon, Dec 12, 2016 at 9:11 AM, Matthew Allen <matthew.allen@citrix.com> wrote:
> On Wed, 2016-12-07 at 16:23 +0000, Ian Jackson wrote:
>> ...
>> I have an alternative concrete suggestion:
>>
>>  Unless there are good reasons to diverge, our suggestions to
>>  discoverer(s) will be based on the following criteria, in order of
>>  precedence:
>>  1. Avoiding disclosure on Fridays, weekends, or on or immediately
>>     before widely respected public holidays.
>>  2. Minimising the number of distinct publication dates
>>     within each 14 day period.
>>  3. Making the preparation period for each advisory as close,
>>     on a log scale, to 14 days as possible.
>>  (The preparation period for an advisory is the period between
>>  predisclosure and publication.)
>> ...
>> Bunfight, anyone ?
>>
>>
>> Ian.
>> (Responding with a personal opinion, and hence from a personal
>>  email address.  I haven't discussed this with my management at
>>  Citrix.)
>>
>
> I'll join in the bunfight with a stronger proposal (noting in passing
> that according to https://xenbits.xen.org/xsa/ we are now expecting 5
> consecutive weeks of XSA announcements):
> 1) Where practical, XSA public disclosures will be batched and announced
> once per month.
> 2) The calendar of disclosure dates will be published well in advance
> and will avoid Fridays, weekends, or dates on or immediately before
> widely respected public holidays.
> 3) Issues will normally have at least 14 days pre-disclosure; this means
> that an issue discovered immediately prior to a scheduled publication
> date will normally not be disclosed until the next publication date.
>
> Clearly there will be times when this can't be done; I am also aware
> that discoverers always have the final say.  But both of those points
> apply to the current policy as well.
>
> I know that this would be a significant change.  However, the present
> frequent and unpredictable nature of disclosures consumes a lot of time
> that would otherwise be better spent on contributing to and improving
> Xen.

I think this assumes that the response is to apply all patches, test
as one unit, and then make available.

OTOH, if you are doing a detailed assessment of each issue,
determining scope of impact, creating regression tests, etc then
batching means that there is a lot more work to fit in a smaller time
period.

Regards,

Anthony Liguori

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

Re: Possible improvement to Xen Security Response Process

[Jan Beulich]

>>> On 12.12.16 at 18:11, <matthew.allen@citrix.com> wrote:
> I'll join in the bunfight with a stronger proposal (noting in passing
> that according to https://xenbits.xen.org/xsa/ we are now expecting 5
> consecutive weeks of XSA announcements):
> 1) Where practical, XSA public disclosures will be batched and announced
> once per month.
> 2) The calendar of disclosure dates will be published well in advance
> and will avoid Fridays, weekends, or dates on or immediately before
> widely respected public holidays.
> 3) Issues will normally have at least 14 days pre-disclosure; this means
> that an issue discovered immediately prior to a scheduled publication
> date will normally not be disclosed until the next publication date.

Hmm - this means 6 weeks of latency in the worst case. I don't
think that's reasonable.

Jan


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

Re: Possible improvement to Xen Security Response Process

[James Bulpin]

On Tue, 2016-12-13 at 08:42, Jan Beulich wrote:
>>>> On 12.12.16 at 18:11, <matthew.allen@citrix.com> wrote:
>> I'll join in the bunfight with a stronger proposal (noting in passing 
>> that according to https://xenbits.xen.org/xsa/ we are now expecting 5 
>> consecutive weeks of XSA announcements):
>> 1) Where practical, XSA public disclosures will be batched and 
>> announced once per month.
>> 2) The calendar of disclosure dates will be published well in advance 
>> and will avoid Fridays, weekends, or dates on or immediately before 
>> widely respected public holidays.
>> 3) Issues will normally have at least 14 days pre-disclosure; this 
>> means that an issue discovered immediately prior to a scheduled 
>> publication date will normally not be disclosed until the next publication date.
>
>Hmm - this means 6 weeks of latency in the worst case. I don't think that's reasonable.

What if instead we adopted a model similar to Microsoft's "patch Tuesday"[1]
where there is always one scheduled release/disclosure date per month and a
second scheduled date two weeks later that is used if needed. As discussed
earlier in this thread we could issue guidance/recommendations to the
discovers on choice of disclosure date - this could be along the lines of
"the second Tuesday in a month that is at least 14 days after the initial
pre-disclosure; in cases where this creates a significant delay, such as
more than 4 weeks, 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).

Thoughts?

Cheers,
James

[1] https://en.wikipedia.org/wiki/Patch_Tuesday
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Possible improvement to Xen Security Response Process

[Jan Beulich]

>>> On 04.01.17 at 12:58, <James.Bulpin@citrix.com> wrote:
> On Tue, 2016-12-13 at 08:42, Jan Beulich wrote:
>>>>> On 12.12.16 at 18:11, <matthew.allen@citrix.com> wrote:
>>> I'll join in the bunfight with a stronger proposal (noting in passing 
>>> that according to https://xenbits.xen.org/xsa/ we are now expecting 5 
>>> consecutive weeks of XSA announcements):
>>> 1) Where practical, XSA public disclosures will be batched and 
>>> announced once per month.
>>> 2) The calendar of disclosure dates will be published well in advance 
>>> and will avoid Fridays, weekends, or dates on or immediately before 
>>> widely respected public holidays.
>>> 3) Issues will normally have at least 14 days pre-disclosure; this 
>>> means that an issue discovered immediately prior to a scheduled 
>>> publication date will normally not be disclosed until the next publication date.
>>
>>Hmm - this means 6 weeks of latency in the worst case. I don't think that's 
> reasonable.
> 
> What if instead we adopted a model similar to Microsoft's "patch Tuesday"[1]
> where there is always one scheduled release/disclosure date per month and a
> second scheduled date two weeks later that is used if needed. As discussed
> earlier in this thread we could issue guidance/recommendations to the
> discovers on choice of disclosure date - this could be along the lines of
> "the second Tuesday in a month that is at least 14 days after the initial
> pre-disclosure; in cases where this creates a significant delay, such as
> more than 4 weeks, 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).

Well, that'll leave us with another fuzzy thing - what does "significant
urgency due to its severity" really mean? The more that depending on
use case, people may have significantly differing opinions on this.

Jan


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

Re: Possible improvement to Xen Security Response Process

[James Bulpin]

On Wed, 2017-01-04 at 13:02, Jan Beulich wrote:
>>>> On 04.01.17 at 12:58, <James.Bulpin@citrix.com> wrote:
>> On Tue, 2016-12-13 at 08:42, Jan Beulich wrote:
>>>>>> On 12.12.16 at 18:11, <matthew.allen@citrix.com> wrote:
>>>> I'll join in the bunfight with a stronger proposal (noting in 
>>>> passing that according to https://xenbits.xen.org/xsa/ we are now 
>>>> expecting 5 consecutive weeks of XSA announcements):
>>>> 1) Where practical, XSA public disclosures will be batched and 
>>>> announced once per month.
>>>> 2) The calendar of disclosure dates will be published well in 
>>>> advance and will avoid Fridays, weekends, or dates on or immediately 
>>>> before widely respected public holidays.
>>>> 3) Issues will normally have at least 14 days pre-disclosure; this 
>>>> means that an issue discovered immediately prior to a scheduled 
>>>> publication date will normally not be disclosed until the next publication date.
>>>
>>>Hmm - this means 6 weeks of latency in the worst case. I don't think 
>>>that's
>> reasonable.
>> 
>> What if instead we adopted a model similar to Microsoft's "patch 
>> Tuesday"[1] where there is always one scheduled release/disclosure 
>> date per month and a second scheduled date two weeks later that is 
>> used if needed. As discussed earlier in this thread we could issue 
>> guidance/recommendations to the discovers on choice of disclosure date 
>> - this could be along the lines of "the second Tuesday in a month that 
>> is at least 14 days after the initial pre-disclosure; in cases where 
>> this creates a significant delay, such as more than 4 weeks, 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).
>
> Well, that'll leave us with another fuzzy thing - what does "significant
> urgency due to its severity" really mean? The more that depending on use
> case, people may have significantly differing opinions on this.

TBH I think a certain amount of fuzziness is unavoidable - I don't think
it's practical or desirable to try to foresee every possible case and
define a rule for it.

I'd rather have a (mostly) predictable schedule for our users even if
that means some fuzziness and the inevitable inconsistency it'll bring,
rather than the current model which appears chaotic to users.

Cheers,
James


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

Re: Possible improvement to Xen Security Response Process

[Ian Jackson]

James Bulpin writes ("Re: [Xen-devel] Possible improvement to Xen Security Response Process"):
> On Tue, 2016-12-13 at 08:42, Jan Beulich wrote:
>> On 12.12.16 at 18:11, <matthew.allen@citrix.com> wrote:
> >
> > Hmm - this means 6 weeks of latency in the worst case. I don't
> > think that's reasonable.
> 
> What if instead we adopted a model similar to Microsoft's "patch
> Tuesday"[1] where there is always one scheduled release/disclosure
> date per month and a second scheduled date two weeks later that is
> used if needed.

If our target emabrgo period is ~14 days, then we should probably have
potential disclosure dates at 2 week intervals.  We could just say
"the Tuesday of an even-numbered week (ISO-8601)".

The rule about trying to avoid widely-observed public holidays would
mean we wouldn't release an advisory on the last Tuesday of the year,
either, so there would not be two consecutive Tuesdays.

> , 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.

If that is acceptable then waiting for the next alternate Tuesday,
such that the embargo period is >=14 days, would work, and we could
write that up as formal wording.

Thanks,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

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

Re: Possible improvement to Xen Security Response Process

[Jan Beulich]

>>> On 20.01.17 at 20:21, <ijackson@chiark.greenend.org.uk> 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.

Jan


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

Re: Possible improvement to Xen Security Response Process

[Lars Kurth]

> On 23 Jan 2017, at 11:30, Jan Beulich <jbeulich@suse.com> wrote:
> 
>>>> On 20.01.17 at 20:21, <ijackson@chiark.greenend.org.uk> 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@lists.xen.org
https://lists.xen.org/xen-devel