[RFC] Propose update of security bug handling process

[RFC] Propose update of security bug handling process

[Wang, Jian J]

Hi,

Currently, we generally follow below process to handle security bugs.
But there're no document to describe the detailed working flow. There're
also discussions on lacking of important information, poor issue description
and no timely notification on update, etc.

       "0 - New Security Bug"
  -> "1 - Triage"
  -> "2 - Mitigation"
  -> "3 - Embargo"
  -> "4 - Disclosure"
  -> "5 - Exit";

I have a proposal at following page to elaborate the process and try to address
all problems reported so far. Following content is for discussion only. Once the
process is finalized, it will be moved to official edk2 wiki page.

https://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-security-issue-process

Any opinions and suggestions are welcomed.

Regards,
Wang, Jian J

Re: [RFC] Propose update of security bug handling process

[Laszlo Ersek]

(Dropping bugs@edk2.groups.io <bugs@edk2.groups.io> from the address
list, as that should be a list to receive automated Bugzilla email.)

On 04/12/19 10:43, Wang, Jian J wrote:
> Hi,
> 
> Currently, we generally follow below process to handle security bugs.
> But there're no document to describe the detailed working flow. There're
> also discussions on lacking of important information, poor issue description
> and no timely notification on update, etc.
> 
>        "0 - New Security Bug"
>   -> "1 - Triage"
>   -> "2 - Mitigation"
>   -> "3 - Embargo"
>   -> "4 - Disclosure"
>   -> "5 - Exit";
> 
> I have a proposal at following page to elaborate the process and try to address
> all problems reported so far. Following content is for discussion only. Once the
> process is finalized, it will be moved to official edk2 wiki page.
> 
> https://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-security-issue-process
> 
> Any opinions and suggestions are welcomed.

Thanks for working on this!

I've skimmed the diagrams. I have one suggestion and one request for
clarification.


- Suggestion: a CVE number should be requested (if appropriate) as soon
as the CVSS score (i.e. the nature of the vulnerability) has been
calculated, and it has been determined whether platforms in practice
(both physical and virtual) are affected.

This is important because vendors should have a common (cross-vendor)
reference for tracking the issue even in their own internal systems, and
this reference should be available to all vendors internally as soon as
upstream determines the issue has security impact.

Additionally, as soon as members begin collaborating on actual patches,
the patches should carry the CVE number in the subject line(s).


- Request for clarification: the Embargo diagram should clarify that
vendors are *forbidden* from shipping fixes in their own products,
regardless of format, until the embargo is lifted. The point of an
embargo is to release/ship the fixes all at once, across all vendors.

It's OK to wait for a while between "3.5 Announce Embargo End", and "4.3
Open BZ To Public" / "4.4 Open source the patch". That's the interval
when vendors would release their fixes all together.

It's *not* OK, for any vendor, to ship their own fixes before "3.5
Announce Embargo End".

Yes, this means that some vendors will have to wait on other vendors,
and some vendors will have to work more hastily than they are used to,
for the sake of other vendors. This is what coordinated/responsible
disclosure means, and it aims to benefit the cumulative user base.

Thanks
Laszlo

Re: [edk2-devel] [RFC] Propose update of security bug handling process

[Wang, Jian J]

Laszlo,


> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Friday, April 12, 2019 8:52 PM
> To: Wang, Jian J <jian.j.wang@intel.com>
> Cc: devel@edk2.groups.io; Zimmer, Vincent <vincent.zimmer@intel.com>;
> Cetola, Stephano <stephano.cetola@intel.com>; Gao, Liming
> <liming.gao@intel.com>
> Subject: Re: [edk2-devel] [RFC] Propose update of security bug handling process
> 
> (Dropping bugs@edk2.groups.io <bugs@edk2.groups.io> from the address
> list, as that should be a list to receive automated Bugzilla email.)
> 
> On 04/12/19 10:43, Wang, Jian J wrote:
> > Hi,
> >
> > Currently, we generally follow below process to handle security bugs.
> > But there're no document to describe the detailed working flow. There're
> > also discussions on lacking of important information, poor issue description
> > and no timely notification on update, etc.
> >
> >        "0 - New Security Bug"
> >   -> "1 - Triage"
> >   -> "2 - Mitigation"
> >   -> "3 - Embargo"
> >   -> "4 - Disclosure"
> >   -> "5 - Exit";
> >
> > I have a proposal at following page to elaborate the process and try to address
> > all problems reported so far. Following content is for discussion only. Once the
> > process is finalized, it will be moved to official edk2 wiki page.
> >
> > https://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-security-
> issue-process
> >
> > Any opinions and suggestions are welcomed.
> 
> Thanks for working on this!
> 
> I've skimmed the diagrams. I have one suggestion and one request for
> clarification.
> 
> 
> - Suggestion: a CVE number should be requested (if appropriate) as soon
> as the CVSS score (i.e. the nature of the vulnerability) has been
> calculated, and it has been determined whether platforms in practice
> (both physical and virtual) are affected.
> 
> This is important because vendors should have a common (cross-vendor)
> reference for tracking the issue even in their own internal systems, and
> this reference should be available to all vendors internally as soon as
> upstream determines the issue has security impact.
> 
> Additionally, as soon as members begin collaborating on actual patches,
> the patches should carry the CVE number in the subject line(s).
> 

No strong opinion. If no objection, let's do as you suggested.

> 
> - Request for clarification: the Embargo diagram should clarify that
> vendors are *forbidden* from shipping fixes in their own products,
> regardless of format, until the embargo is lifted. The point of an
> embargo is to release/ship the fixes all at once, across all vendors.
> 
> It's OK to wait for a while between "3.5 Announce Embargo End", and "4.3
> Open BZ To Public" / "4.4 Open source the patch". That's the interval
> when vendors would release their fixes all together.
> 
> It's *not* OK, for any vendor, to ship their own fixes before "3.5
> Announce Embargo End".
> 
> Yes, this means that some vendors will have to wait on other vendors,
> and some vendors will have to work more hastily than they are used to,
> for the sake of other vendors. This is what coordinated/responsible
> disclosure means, and it aims to benefit the cumulative user base.

I think it's impractical to ask all vendors to release the fixes at the same
time. The longer a security issue exists in a product, the more damage
may be caused potentially. I don't think any vendor want to risk that. But
it's reasonable and feasible to ask vendors not to expose the issue details
in the embargo period.

So my understanding is that embargo is for preparing the security issue
information disclosure purpose, during which all vendors should integrate
the mitigation solution into their products. Actually, once someone else
find the same issue and open it to public in the period, we should end the
embargo immediately. This step is missing in the work flow chart.

Vincent, please correct me if anything wrong here.

Regards,
Jian
> 
> Thanks
> Laszlo
> 
> 

Re: [edk2-devel] [RFC] Propose update of security bug handling process

[Laszlo Ersek]

On 04/15/19 07:36, Wang, Jian J wrote:
> Laszlo,
> 
> 
>> -----Original Message-----
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Laszlo Ersek
>> Sent: Friday, April 12, 2019 8:52 PM
>> To: Wang, Jian J <jian.j.wang@intel.com>
>> Cc: devel@edk2.groups.io; Zimmer, Vincent <vincent.zimmer@intel.com>;
>> Cetola, Stephano <stephano.cetola@intel.com>; Gao, Liming
>> <liming.gao@intel.com>
>> Subject: Re: [edk2-devel] [RFC] Propose update of security bug handling process
>>
>> (Dropping bugs@edk2.groups.io <bugs@edk2.groups.io> from the address
>> list, as that should be a list to receive automated Bugzilla email.)
>>
>> On 04/12/19 10:43, Wang, Jian J wrote:
>>> Hi,
>>>
>>> Currently, we generally follow below process to handle security bugs.
>>> But there're no document to describe the detailed working flow. There're
>>> also discussions on lacking of important information, poor issue description
>>> and no timely notification on update, etc.
>>>
>>>        "0 - New Security Bug"
>>>   -> "1 - Triage"
>>>   -> "2 - Mitigation"
>>>   -> "3 - Embargo"
>>>   -> "4 - Disclosure"
>>>   -> "5 - Exit";
>>>
>>> I have a proposal at following page to elaborate the process and try to address
>>> all problems reported so far. Following content is for discussion only. Once the
>>> process is finalized, it will be moved to official edk2 wiki page.
>>>
>>> https://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-security-
>> issue-process
>>>
>>> Any opinions and suggestions are welcomed.
>>
>> Thanks for working on this!
>>
>> I've skimmed the diagrams. I have one suggestion and one request for
>> clarification.
>>
>>
>> - Suggestion: a CVE number should be requested (if appropriate) as soon
>> as the CVSS score (i.e. the nature of the vulnerability) has been
>> calculated, and it has been determined whether platforms in practice
>> (both physical and virtual) are affected.
>>
>> This is important because vendors should have a common (cross-vendor)
>> reference for tracking the issue even in their own internal systems, and
>> this reference should be available to all vendors internally as soon as
>> upstream determines the issue has security impact.
>>
>> Additionally, as soon as members begin collaborating on actual patches,
>> the patches should carry the CVE number in the subject line(s).
>>
> 
> No strong opinion. If no objection, let's do as you suggested.
> 
>>
>> - Request for clarification: the Embargo diagram should clarify that
>> vendors are *forbidden* from shipping fixes in their own products,
>> regardless of format, until the embargo is lifted. The point of an
>> embargo is to release/ship the fixes all at once, across all vendors.
>>
>> It's OK to wait for a while between "3.5 Announce Embargo End", and "4.3
>> Open BZ To Public" / "4.4 Open source the patch". That's the interval
>> when vendors would release their fixes all together.
>>
>> It's *not* OK, for any vendor, to ship their own fixes before "3.5
>> Announce Embargo End".
>>
>> Yes, this means that some vendors will have to wait on other vendors,
>> and some vendors will have to work more hastily than they are used to,
>> for the sake of other vendors. This is what coordinated/responsible
>> disclosure means, and it aims to benefit the cumulative user base.
> 
> I think it's impractical to ask all vendors to release the fixes at the same
> time.

They don't need to agree on the latest date to release the fix. They
need to agree on the earliest date of release though. That's the *point*
of an embargo.

Assume Red Hat is invited to discuss a security issue in one of the edk2
modules that affects OVMF. Red Hat participates in the analysis, patch
review, maybe Red Hat even contributes one or two of the patches. (We
could even report a security issue in the first place; there have been
examples.)

After a bit of work, everyone agrees that patches prepared by the
infosec group are fine, and we set an embargo / earliest release date,
before informing the grand public, and posting the upstream patches to
edk2-devel.

However, assume that every vendor is permitted to ship the fixes
whenever they want, in their own products. Great, Red Hat ships the OVMF
firmware as host-OS *software* packages, as binary and as *source* RPMs.
So, if involved vendors themselves are not required to adhere to the
embargo in their own products, then let's say Red Hat ships the patches
in *source code* form, complete with issue description / commit
messages, in just two weeks after the patches are considered
functionally appropriate, by the infosec group.

All the while physical platform vendors might need half a year or more.

Would all vendors like that? I don't think so.

And, if Red Hat is expected to wait for physical vendors, we certainly
expect the same in return.

This is not a theoretical question: until now, we've *significantly*
delayed product features at least twice, waiting for physical firmware
vendors, under security issues that we have reported.

> The longer a security issue exists in a product, the more damage
> may be caused potentially.

No doubt.

This is why setting embargo dates is a trade-off. Any given vendor wants
to get the fix as quickly as possible to its own users, obviously. At
the same time, they should not screw over the users of *other* vendors
(e.g. users of their competitors) -- so that next time, they can
reasonably expect the other vendors to wait for them, in exchange.

All vendors need to take some extra risk in order to protect the users
of the *other* vendors. How long exactly vendors are willing to wait for
each other should be a case-by-case discussion, but the generic
principle is that they do set a *common* earliest release date.

> I don't think any vendor want to risk that. But
> it's reasonable and feasible to ask vendors not to expose the issue details
> in the embargo period.

I disagree.

What you describe implies shipping the fix in binary-only form, or with
other means of obfuscation.

This would hugely discriminate against open source vendors, as they ship
all fixes (security or not) in both binary and source form.

> So my understanding is that embargo is for preparing the security issue
> information disclosure purpose, during which all vendors should integrate
> the mitigation solution into their products.

Integrate into their products: yes. Release to their users: no.

> Actually, once someone else
> find the same issue and open it to public in the period, we should end the
> embargo immediately. This step is missing in the work flow chart.

Agreed!

Thanks,
Laszlo

> Vincent, please correct me if anything wrong here.
> 
> Regards,
> Jian
>>
>> Thanks
>> Laszlo
>>
>> 
> 

Re: [edk2-devel] [RFC] Propose update of security bug handling process

[Wang, Jian J]

Laszlo,

I got your point, and understood the requirements for source released platforms.
I think it's something needing all vendors who have concerns to get agreement
with. It's part of 'optimization' Vincent mentioned in another email. Stephano
will set up meetings to drive related discussions.

Jian

> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Tuesday, April 16, 2019 1:04 AM
> To: Wang, Jian J <jian.j.wang@intel.com>; devel@edk2.groups.io
> Cc: Zimmer, Vincent <vincent.zimmer@intel.com>; Cetola, Stephano
> <stephano.cetola@intel.com>; Gao, Liming <liming.gao@intel.com>
> Subject: Re: [edk2-devel] [RFC] Propose update of security bug handling process
> 
> On 04/15/19 07:36, Wang, Jian J wrote:
> > Laszlo,
> >
> >
> >> -----Original Message-----
> >> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >> Laszlo Ersek
> >> Sent: Friday, April 12, 2019 8:52 PM
> >> To: Wang, Jian J <jian.j.wang@intel.com>
> >> Cc: devel@edk2.groups.io; Zimmer, Vincent <vincent.zimmer@intel.com>;
> >> Cetola, Stephano <stephano.cetola@intel.com>; Gao, Liming
> >> <liming.gao@intel.com>
> >> Subject: Re: [edk2-devel] [RFC] Propose update of security bug handling
> process
> >>
> >> (Dropping bugs@edk2.groups.io <bugs@edk2.groups.io> from the address
> >> list, as that should be a list to receive automated Bugzilla email.)
> >>
> >> On 04/12/19 10:43, Wang, Jian J wrote:
> >>> Hi,
> >>>
> >>> Currently, we generally follow below process to handle security bugs.
> >>> But there're no document to describe the detailed working flow. There're
> >>> also discussions on lacking of important information, poor issue description
> >>> and no timely notification on update, etc.
> >>>
> >>>        "0 - New Security Bug"
> >>>   -> "1 - Triage"
> >>>   -> "2 - Mitigation"
> >>>   -> "3 - Embargo"
> >>>   -> "4 - Disclosure"
> >>>   -> "5 - Exit";
> >>>
> >>> I have a proposal at following page to elaborate the process and try to
> address
> >>> all problems reported so far. Following content is for discussion only. Once
> the
> >>> process is finalized, it will be moved to official edk2 wiki page.
> >>>
> >>> https://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-security-
> >> issue-process
> >>>
> >>> Any opinions and suggestions are welcomed.
> >>
> >> Thanks for working on this!
> >>
> >> I've skimmed the diagrams. I have one suggestion and one request for
> >> clarification.
> >>
> >>
> >> - Suggestion: a CVE number should be requested (if appropriate) as soon
> >> as the CVSS score (i.e. the nature of the vulnerability) has been
> >> calculated, and it has been determined whether platforms in practice
> >> (both physical and virtual) are affected.
> >>
> >> This is important because vendors should have a common (cross-vendor)
> >> reference for tracking the issue even in their own internal systems, and
> >> this reference should be available to all vendors internally as soon as
> >> upstream determines the issue has security impact.
> >>
> >> Additionally, as soon as members begin collaborating on actual patches,
> >> the patches should carry the CVE number in the subject line(s).
> >>
> >
> > No strong opinion. If no objection, let's do as you suggested.
> >
> >>
> >> - Request for clarification: the Embargo diagram should clarify that
> >> vendors are *forbidden* from shipping fixes in their own products,
> >> regardless of format, until the embargo is lifted. The point of an
> >> embargo is to release/ship the fixes all at once, across all vendors.
> >>
> >> It's OK to wait for a while between "3.5 Announce Embargo End", and "4.3
> >> Open BZ To Public" / "4.4 Open source the patch". That's the interval
> >> when vendors would release their fixes all together.
> >>
> >> It's *not* OK, for any vendor, to ship their own fixes before "3.5
> >> Announce Embargo End".
> >>
> >> Yes, this means that some vendors will have to wait on other vendors,
> >> and some vendors will have to work more hastily than they are used to,
> >> for the sake of other vendors. This is what coordinated/responsible
> >> disclosure means, and it aims to benefit the cumulative user base.
> >
> > I think it's impractical to ask all vendors to release the fixes at the same
> > time.
> 
> They don't need to agree on the latest date to release the fix. They
> need to agree on the earliest date of release though. That's the *point*
> of an embargo.
> 
> Assume Red Hat is invited to discuss a security issue in one of the edk2
> modules that affects OVMF. Red Hat participates in the analysis, patch
> review, maybe Red Hat even contributes one or two of the patches. (We
> could even report a security issue in the first place; there have been
> examples.)
> 
> After a bit of work, everyone agrees that patches prepared by the
> infosec group are fine, and we set an embargo / earliest release date,
> before informing the grand public, and posting the upstream patches to
> edk2-devel.
> 
> However, assume that every vendor is permitted to ship the fixes
> whenever they want, in their own products. Great, Red Hat ships the OVMF
> firmware as host-OS *software* packages, as binary and as *source* RPMs.
> So, if involved vendors themselves are not required to adhere to the
> embargo in their own products, then let's say Red Hat ships the patches
> in *source code* form, complete with issue description / commit
> messages, in just two weeks after the patches are considered
> functionally appropriate, by the infosec group.
> 
> All the while physical platform vendors might need half a year or more.
> 
> Would all vendors like that? I don't think so.
> 
> And, if Red Hat is expected to wait for physical vendors, we certainly
> expect the same in return.
> 
> This is not a theoretical question: until now, we've *significantly*
> delayed product features at least twice, waiting for physical firmware
> vendors, under security issues that we have reported.
> 
> > The longer a security issue exists in a product, the more damage
> > may be caused potentially.
> 
> No doubt.
> 
> This is why setting embargo dates is a trade-off. Any given vendor wants
> to get the fix as quickly as possible to its own users, obviously. At
> the same time, they should not screw over the users of *other* vendors
> (e.g. users of their competitors) -- so that next time, they can
> reasonably expect the other vendors to wait for them, in exchange.
> 
> All vendors need to take some extra risk in order to protect the users
> of the *other* vendors. How long exactly vendors are willing to wait for
> each other should be a case-by-case discussion, but the generic
> principle is that they do set a *common* earliest release date.
> 
> > I don't think any vendor want to risk that. But
> > it's reasonable and feasible to ask vendors not to expose the issue details
> > in the embargo period.
> 
> I disagree.
> 
> What you describe implies shipping the fix in binary-only form, or with
> other means of obfuscation.
> 
> This would hugely discriminate against open source vendors, as they ship
> all fixes (security or not) in both binary and source form.
> 
> > So my understanding is that embargo is for preparing the security issue
> > information disclosure purpose, during which all vendors should integrate
> > the mitigation solution into their products.
> 
> Integrate into their products: yes. Release to their users: no.
> 
> > Actually, once someone else
> > find the same issue and open it to public in the period, we should end the
> > embargo immediately. This step is missing in the work flow chart.
> 
> Agreed!
> 
> Thanks,
> Laszlo
> 
> > Vincent, please correct me if anything wrong here.
> >
> > Regards,
> > Jian
> >>
> >> Thanks
> >> Laszlo
> >>
> >>
> >
> 
> 
> 

Re: [edk2-devel] [RFC] Propose update of security bug handling process

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 8440 bytes --]



> On Apr 15, 2019, at 11:06 PM, Wang, Jian J <jian.j.wang@intel.com> wrote:
> 
> Laszlo,
> 
> I got your point, and understood the requirements for source released platforms.
> I think it's something needing all vendors who have concerns to get agreement
> with. It's part of 'optimization' Vincent mentioned in another email. Stephano
> will set up meetings to drive related discussions.
> 

As Laszlo points out we are an open source project. Seems like how to release binaries is more the purview of the UEFI USRT, so I agree a meeting is a good idea. 

Thanks,

Andrew Fish

> Jian
> 
>> -----Original Message-----
>> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>] On Behalf Of
>> Laszlo Ersek
>> Sent: Tuesday, April 16, 2019 1:04 AM
>> To: Wang, Jian J <jian.j.wang@intel.com <mailto:jian.j.wang@intel.com>>; devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>> Cc: Zimmer, Vincent <vincent.zimmer@intel.com <mailto:vincent.zimmer@intel.com>>; Cetola, Stephano
>> <stephano.cetola@intel.com <mailto:stephano.cetola@intel.com>>; Gao, Liming <liming.gao@intel.com <mailto:liming.gao@intel.com>>
>> Subject: Re: [edk2-devel] [RFC] Propose update of security bug handling process
>> 
>> On 04/15/19 07:36, Wang, Jian J wrote:
>>> Laszlo,
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>>>> Laszlo Ersek
>>>> Sent: Friday, April 12, 2019 8:52 PM
>>>> To: Wang, Jian J <jian.j.wang@intel.com>
>>>> Cc: devel@edk2.groups.io; Zimmer, Vincent <vincent.zimmer@intel.com>;
>>>> Cetola, Stephano <stephano.cetola@intel.com>; Gao, Liming
>>>> <liming.gao@intel.com>
>>>> Subject: Re: [edk2-devel] [RFC] Propose update of security bug handling
>> process
>>>> 
>>>> (Dropping bugs@edk2.groups.io <bugs@edk2.groups.io> from the address
>>>> list, as that should be a list to receive automated Bugzilla email.)
>>>> 
>>>> On 04/12/19 10:43, Wang, Jian J wrote:
>>>>> Hi,
>>>>> 
>>>>> Currently, we generally follow below process to handle security bugs.
>>>>> But there're no document to describe the detailed working flow. There're
>>>>> also discussions on lacking of important information, poor issue description
>>>>> and no timely notification on update, etc.
>>>>> 
>>>>>       "0 - New Security Bug"
>>>>>  -> "1 - Triage"
>>>>>  -> "2 - Mitigation"
>>>>>  -> "3 - Embargo"
>>>>>  -> "4 - Disclosure"
>>>>>  -> "5 - Exit";
>>>>> 
>>>>> I have a proposal at following page to elaborate the process and try to
>> address
>>>>> all problems reported so far. Following content is for discussion only. Once
>> the
>>>>> process is finalized, it will be moved to official edk2 wiki page.
>>>>> 
>>>>> https://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-security-
>>>> issue-process
>>>>> 
>>>>> Any opinions and suggestions are welcomed.
>>>> 
>>>> Thanks for working on this!
>>>> 
>>>> I've skimmed the diagrams. I have one suggestion and one request for
>>>> clarification.
>>>> 
>>>> 
>>>> - Suggestion: a CVE number should be requested (if appropriate) as soon
>>>> as the CVSS score (i.e. the nature of the vulnerability) has been
>>>> calculated, and it has been determined whether platforms in practice
>>>> (both physical and virtual) are affected.
>>>> 
>>>> This is important because vendors should have a common (cross-vendor)
>>>> reference for tracking the issue even in their own internal systems, and
>>>> this reference should be available to all vendors internally as soon as
>>>> upstream determines the issue has security impact.
>>>> 
>>>> Additionally, as soon as members begin collaborating on actual patches,
>>>> the patches should carry the CVE number in the subject line(s).
>>>> 
>>> 
>>> No strong opinion. If no objection, let's do as you suggested.
>>> 
>>>> 
>>>> - Request for clarification: the Embargo diagram should clarify that
>>>> vendors are *forbidden* from shipping fixes in their own products,
>>>> regardless of format, until the embargo is lifted. The point of an
>>>> embargo is to release/ship the fixes all at once, across all vendors.
>>>> 
>>>> It's OK to wait for a while between "3.5 Announce Embargo End", and "4.3
>>>> Open BZ To Public" / "4.4 Open source the patch". That's the interval
>>>> when vendors would release their fixes all together.
>>>> 
>>>> It's *not* OK, for any vendor, to ship their own fixes before "3.5
>>>> Announce Embargo End".
>>>> 
>>>> Yes, this means that some vendors will have to wait on other vendors,
>>>> and some vendors will have to work more hastily than they are used to,
>>>> for the sake of other vendors. This is what coordinated/responsible
>>>> disclosure means, and it aims to benefit the cumulative user base.
>>> 
>>> I think it's impractical to ask all vendors to release the fixes at the same
>>> time.
>> 
>> They don't need to agree on the latest date to release the fix. They
>> need to agree on the earliest date of release though. That's the *point*
>> of an embargo.
>> 
>> Assume Red Hat is invited to discuss a security issue in one of the edk2
>> modules that affects OVMF. Red Hat participates in the analysis, patch
>> review, maybe Red Hat even contributes one or two of the patches. (We
>> could even report a security issue in the first place; there have been
>> examples.)
>> 
>> After a bit of work, everyone agrees that patches prepared by the
>> infosec group are fine, and we set an embargo / earliest release date,
>> before informing the grand public, and posting the upstream patches to
>> edk2-devel.
>> 
>> However, assume that every vendor is permitted to ship the fixes
>> whenever they want, in their own products. Great, Red Hat ships the OVMF
>> firmware as host-OS *software* packages, as binary and as *source* RPMs.
>> So, if involved vendors themselves are not required to adhere to the
>> embargo in their own products, then let's say Red Hat ships the patches
>> in *source code* form, complete with issue description / commit
>> messages, in just two weeks after the patches are considered
>> functionally appropriate, by the infosec group.
>> 
>> All the while physical platform vendors might need half a year or more.
>> 
>> Would all vendors like that? I don't think so.
>> 
>> And, if Red Hat is expected to wait for physical vendors, we certainly
>> expect the same in return.
>> 
>> This is not a theoretical question: until now, we've *significantly*
>> delayed product features at least twice, waiting for physical firmware
>> vendors, under security issues that we have reported.
>> 
>>> The longer a security issue exists in a product, the more damage
>>> may be caused potentially.
>> 
>> No doubt.
>> 
>> This is why setting embargo dates is a trade-off. Any given vendor wants
>> to get the fix as quickly as possible to its own users, obviously. At
>> the same time, they should not screw over the users of *other* vendors
>> (e.g. users of their competitors) -- so that next time, they can
>> reasonably expect the other vendors to wait for them, in exchange.
>> 
>> All vendors need to take some extra risk in order to protect the users
>> of the *other* vendors. How long exactly vendors are willing to wait for
>> each other should be a case-by-case discussion, but the generic
>> principle is that they do set a *common* earliest release date.
>> 
>>> I don't think any vendor want to risk that. But
>>> it's reasonable and feasible to ask vendors not to expose the issue details
>>> in the embargo period.
>> 
>> I disagree.
>> 
>> What you describe implies shipping the fix in binary-only form, or with
>> other means of obfuscation.
>> 
>> This would hugely discriminate against open source vendors, as they ship
>> all fixes (security or not) in both binary and source form.
>> 
>>> So my understanding is that embargo is for preparing the security issue
>>> information disclosure purpose, during which all vendors should integrate
>>> the mitigation solution into their products.
>> 
>> Integrate into their products: yes. Release to their users: no.
>> 
>>> Actually, once someone else
>>> find the same issue and open it to public in the period, we should end the
>>> embargo immediately. This step is missing in the work flow chart.
>> 
>> Agreed!
>> 
>> Thanks,
>> Laszlo
>> 
>>> Vincent, please correct me if anything wrong here.
>>> 
>>> Regards,
>>> Jian
>>>> 
>>>> Thanks
>>>> Laszlo
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 19133 bytes --]

Re: [edk2-devel] [RFC] Propose update of security bug handling process

[Vincent Zimmer]

I agree w/ your comments Jian. Great input from Lazlo, too.

I also want to let the community know that this specific process posting has 2 parts.

This first was to post the process used by infosec bz team today, which Jian did well with https://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-security-issue-process.  Goal is to provide transparency into a process that we all agree can use some 'optimization.'

The 'optimization' is the second part of the discussion, namely refining the process, and some of the results of the RFC. To that end, our able community manager Stephano will set up meetings for continuing to execute the scrubs in addition to and/or along with actions to refine the process.

Thanks,

Vincent

-----Original Message-----
From: Wang, Jian J 
Sent: Sunday, April 14, 2019 10:36 PM
To: devel@edk2.groups.io; lersek@redhat.com
Cc: Zimmer, Vincent <vincent.zimmer@intel.com>; Cetola, Stephano <stephano.cetola@intel.com>; Gao, Liming <liming.gao@intel.com>
Subject: RE: [edk2-devel] [RFC] Propose update of security bug handling process

Laszlo,


> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> Laszlo Ersek
> Sent: Friday, April 12, 2019 8:52 PM
> To: Wang, Jian J <jian.j.wang@intel.com>
> Cc: devel@edk2.groups.io; Zimmer, Vincent <vincent.zimmer@intel.com>; 
> Cetola, Stephano <stephano.cetola@intel.com>; Gao, Liming 
> <liming.gao@intel.com>
> Subject: Re: [edk2-devel] [RFC] Propose update of security bug 
> handling process
> 
> (Dropping bugs@edk2.groups.io <bugs@edk2.groups.io> from the address 
> list, as that should be a list to receive automated Bugzilla email.)
> 
> On 04/12/19 10:43, Wang, Jian J wrote:
> > Hi,
> >
> > Currently, we generally follow below process to handle security bugs.
> > But there're no document to describe the detailed working flow. 
> > There're also discussions on lacking of important information, poor 
> > issue description and no timely notification on update, etc.
> >
> >        "0 - New Security Bug"
> >   -> "1 - Triage"
> >   -> "2 - Mitigation"
> >   -> "3 - Embargo"
> >   -> "4 - Disclosure"
> >   -> "5 - Exit";
> >
> > I have a proposal at following page to elaborate the process and try 
> > to address all problems reported so far. Following content is for 
> > discussion only. Once the process is finalized, it will be moved to official edk2 wiki page.
> >
> > https://github.com/jwang36/tianocore.github.io/wiki/Proposal-of-secu
> > rity-
> issue-process
> >
> > Any opinions and suggestions are welcomed.
> 
> Thanks for working on this!
> 
> I've skimmed the diagrams. I have one suggestion and one request for 
> clarification.
> 
> 
> - Suggestion: a CVE number should be requested (if appropriate) as 
> soon as the CVSS score (i.e. the nature of the vulnerability) has been 
> calculated, and it has been determined whether platforms in practice 
> (both physical and virtual) are affected.
> 
> This is important because vendors should have a common (cross-vendor) 
> reference for tracking the issue even in their own internal systems, 
> and this reference should be available to all vendors internally as 
> soon as upstream determines the issue has security impact.
> 
> Additionally, as soon as members begin collaborating on actual 
> patches, the patches should carry the CVE number in the subject line(s).
> 

No strong opinion. If no objection, let's do as you suggested.

> 
> - Request for clarification: the Embargo diagram should clarify that 
> vendors are *forbidden* from shipping fixes in their own products, 
> regardless of format, until the embargo is lifted. The point of an 
> embargo is to release/ship the fixes all at once, across all vendors.
> 
> It's OK to wait for a while between "3.5 Announce Embargo End", and 
> "4.3 Open BZ To Public" / "4.4 Open source the patch". That's the 
> interval when vendors would release their fixes all together.
> 
> It's *not* OK, for any vendor, to ship their own fixes before "3.5 
> Announce Embargo End".
> 
> Yes, this means that some vendors will have to wait on other vendors, 
> and some vendors will have to work more hastily than they are used to, 
> for the sake of other vendors. This is what coordinated/responsible 
> disclosure means, and it aims to benefit the cumulative user base.

I think it's impractical to ask all vendors to release the fixes at the same time. The longer a security issue exists in a product, the more damage may be caused potentially. I don't think any vendor want to risk that. But it's reasonable and feasible to ask vendors not to expose the issue details in the embargo period.

So my understanding is that embargo is for preparing the security issue information disclosure purpose, during which all vendors should integrate the mitigation solution into their products. Actually, once someone else find the same issue and open it to public in the period, we should end the embargo immediately. This step is missing in the work flow chart.

Vincent, please correct me if anything wrong here.

Regards,
Jian
> 
> Thanks
> Laszlo
> 
>