Suggested changes to the admission policy of the vulnerability pre-disclosure list

Suggested changes to the admission policy of the vulnerability pre-disclosure list

[Charles-H. Schulz]

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

Hello,

I /we /Vates would like to suggest some changes to the policy regarding the
enrollment to the pre-disclosure mailing list of the Xen Security Team.

We have had some talks with the French national CERT who has a need to be the
recipient of such a list. This national CERT -and in my experience other
national CERTs such as the NIST for instance- is in constant contact with a
large Xen userbase that is mostly made up of large parts of the public sector
as well as critical infrastructure operators belonging to the private
sector. For confidentiality reasons they cannot disclose who uses Xen and
where it is used nor who may be using it internally or within the related
national cybersecurity authority.

Because of that, their request may not be clear or matching the existing
criteria for inclusion in the mailing list. National CERTs are trusted
actors and have historically been among the very first entities to define,
advocate for and put in practice the very notion of responsible
disclosure. Much of the current practice of Open Source projects in that
regard actually stems from CERTs. As part of their policies and processes
regarding vulnerability disclosure, the notion of confidentiality and
documented, waterfall-like processes of disclosure is play an integral
part of
how they handle informaton and publicity around vulnerability. As a result,
national CERTs (and the French National CERT) do not spread undisclosed
vulnerability without following established and agreed-upon processes. Such
processes include, in our instance, the ones defined and followed by the Xen
Security Team. Compliance with these are the first criteria to earn trust and
respect from the ecosystem and the downstream users. You can see an example
of their work here: https://www.cert.ssi.gouv.fr/

Part of the mission of the French National CERT is to work with
critical infrastructure providers in securing their IT.
This kind of expertise entails the securing of these information
systems before any unforeseen incident as well as after the incident
(incident remediation).
None of the tasks involved imply the communication of zero-day types
of vulnerabilities or vulnerabilities that are unpublished to the
downstream users.

I hope this clarifies the request and I'm looking forward to your feedback.

Best regards,

-- 
Charles-H. Schulz
Chief Strategy Officer - CSO
XCP-ng & Xen Orchestra - Vates solutions


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 866 bytes --]

Re: Suggested changes to the admission policy of the vulnerability pre-disclosure list

[Jan Beulich]

On 15.07.2021 23:23, Charles-H. Schulz wrote:
> Hello,
> 
> I /we /Vates would like to suggest some changes to the policy regarding the
> enrollment to the pre-disclosure mailing list of the Xen Security Team.
> 
> We have had some talks with the French national CERT who has a need to be the
> recipient of such a list. This national CERT -and in my experience other
> national CERTs such as the NIST for instance- is in constant contact with a
> large Xen userbase that is mostly made up of large parts of the public sector
> as well as critical infrastructure operators belonging to the private
> sector. For confidentiality reasons they cannot disclose who uses Xen and
> where it is used nor who may be using it internally or within the related
> national cybersecurity authority.
> 
> Because of that, their request may not be clear or matching the existing
> criteria for inclusion in the mailing list. National CERTs are trusted
> actors and have historically been among the very first entities to define,
> advocate for and put in practice the very notion of responsible
> disclosure. Much of the current practice of Open Source projects in that
> regard actually stems from CERTs. As part of their policies and processes
> regarding vulnerability disclosure, the notion of confidentiality and
> documented, waterfall-like processes of disclosure is play an integral
> part of
> how they handle informaton and publicity around vulnerability. As a result,
> national CERTs (and the French National CERT) do not spread undisclosed
> vulnerability without following established and agreed-upon processes. Such
> processes include, in our instance, the ones defined and followed by the Xen
> Security Team. Compliance with these are the first criteria to earn trust and
> respect from the ecosystem and the downstream users. You can see an example
> of their work here: https://www.cert.ssi.gouv.fr/
> 
> Part of the mission of the French National CERT is to work with
> critical infrastructure providers in securing their IT.
> This kind of expertise entails the securing of these information
> systems before any unforeseen incident as well as after the incident
> (incident remediation).
> None of the tasks involved imply the communication of zero-day types
> of vulnerabilities or vulnerabilities that are unpublished to the
> downstream users.

Would you mind shedding some light on the benefits of a national CERT
being in the know of unpublished vulnerabilities when they can't share
that knowledge with their downstreams, and hence their downstreams -
as long as they aren't themselves members of our predisclosure list -
would still be zero-dayed at the time of publication of such
vulnerabilities? Shouldn't their advice to their downstreams rather be
to direct them towards applying for pre-disclosure list membership?

As to the actual policy - how would you propose to categorize such
organizations, i.e. how would a new bullet point in the present

"
This includes:

    Public hosting providers;
    Large-scale organisational users of Xen;
    Vendors of Xen-based systems;
    Distributors of operating systems with Xen support.
"

look like in your opinion? This is pretty important imo, as it will
need to be understood who else might then become eligible.

Jan

Re: Suggested changes to the admission policy of the vulnerability pre-disclosure list

[Charles-H. Schulz]

Hello,

Jan Beulich @ 2021-07-16 09:52 CEST:

> On 15.07.2021 23:23, Charles-H. Schulz wrote:
>> Hello,
>> 
>> I /we /Vates would like to suggest some changes to the policy regarding the
>> enrollment to the pre-disclosure mailing list of the Xen Security Team.
>> 
>> We have had some talks with the French national CERT who has a need to be the
>> recipient of such a list. This national CERT -and in my experience other
>> national CERTs such as the NIST for instance- is in constant contact with a
>> large Xen userbase that is mostly made up of large parts of the public sector
>> as well as critical infrastructure operators belonging to the private
>> sector. For confidentiality reasons they cannot disclose who uses Xen and
>> where it is used nor who may be using it internally or within the related
>> national cybersecurity authority.
>> 
>> Because of that, their request may not be clear or matching the existing
>> criteria for inclusion in the mailing list. National CERTs are trusted
>> actors and have historically been among the very first entities to define,
>> advocate for and put in practice the very notion of responsible
>> disclosure. Much of the current practice of Open Source projects in that
>> regard actually stems from CERTs. As part of their policies and processes
>> regarding vulnerability disclosure, the notion of confidentiality and
>> documented, waterfall-like processes of disclosure is play an integral
>> part of
>> how they handle informaton and publicity around vulnerability. As a result,
>> national CERTs (and the French National CERT) do not spread undisclosed
>> vulnerability without following established and agreed-upon processes. Such
>> processes include, in our instance, the ones defined and followed by the Xen
>> Security Team. Compliance with these are the first criteria to earn trust and
>> respect from the ecosystem and the downstream users. You can see an example
>> of their work here: https://www.cert.ssi.gouv.fr/
>> 
>> Part of the mission of the French National CERT is to work with
>> critical infrastructure providers in securing their IT.
>> This kind of expertise entails the securing of these information
>> systems before any unforeseen incident as well as after the incident
>> (incident remediation).
>> None of the tasks involved imply the communication of zero-day types
>> of vulnerabilities or vulnerabilities that are unpublished to the
>> downstream users.
>
> Would you mind shedding some light on the benefits of a national CERT
> being in the know of unpublished vulnerabilities when they can't share
> that knowledge with their downstreams, and hence their downstreams -
> as long as they aren't themselves members of our predisclosure list -
> would still be zero-dayed at the time of publication of such
> vulnerabilities? Shouldn't their advice to their downstreams rather be
> to direct them towards applying for pre-disclosure list membership?

In practice, most of the downstream users that the CERTs work with are not
going to subscribe to the Xen pre-disclosure list, nor to any pre-disclosure
lists of vendors or Open Source Software projects. The downstream users will
work with CERTs and various cybersecurity service providers (Security
Operations Centers -SOCs- being a typical example) in order for vulnerability
discovery, disclosure, patching and later integration of fixes or remediatory
measures be managed and applied.

So a national CERT being in the loop of such advanced, upstream vulnerability
pre-disclosures list is pretty much what a CERT does when it's not publishing
security advisories of some kind. There are several benefits for a CERT:
- threat intelligence and analysis: one vulnerability discovered in one
  source may not be an isolated "incident" - it may be connected to a broader
  attack made of the exploitation of several vulnerabilities found across
  different software stacks. This also providers valuable information about the
  threat landscape and relevance. For instance, Xen having several
  vulnerability reports is one thing, but what happens if KVM receives a batch
  of previously unknown vulnerabilities roughly at the same time? For a CERT,
  that level of information can be very important (sometimes "national
  security" important)

- because of a CERT being a nexus of several threat information/intelligence
  by being as upstream as it can on critical software components, it can then
  act -not by disclosing or patching yet unpublished vulnerabilities on its
  own- by setting the effective patching and remediation work on the
  information systems it is in charge of protecting. In the case of a
  national CERT, such as the CERT-FR, that would be the French central
  administration networks and information systems. Essentially it would
  prioritize the response given the specific level and nature  of threats and the
  presence of vulnerabilities on the systems (i.e: first patch MS Office,
  then Apache httpd, then the vulnerability XYZ00123 on Xen as it really
  affects only a small part of our Xen deployments).

- last but not least, CERTs act as central vulnerability reports
  "broadcasters". CERT users/subscribers/clients point to CERTs to receive
  their daily security watch and alerts. 

>
> As to the actual policy - how would you propose to categorize such
> organizations, i.e. how would a new bullet point in the present
>
> "
> This includes:
>
>     Public hosting providers;
>     Large-scale organisational users of Xen;
>     Vendors of Xen-based systems;
>     Distributors of operating systems with Xen support.
> "
>
> look like in your opinion? This is pretty important imo, as it will
> need to be understood who else might then become eligible.

I think it's either a very difficult or a very simple question. If I were to
suggest to simply add a line with "national CERTs" meaning: CERTs that
operate on behalf of governments for the protection and cybersecurity watch
of national administration and critical infrastructures" would that be
accepted? I'm happy with that one. It's really two criteria I'm adding: being
a CERTs acting wth a clear mandate from a national authority to serve as the
national computing emergency response team. Not sure how satisfactory that
is.

All the best,
-- 
Charles-H. Schulz
Chief Strategy Officer - CSO
XCP-ng & Xen Orchestra - Vates solutions

Re: Suggested changes to the admission policy of the vulnerability pre-disclosure list

[Jan Beulich]

On 16.07.2021 15:13, Charles-H. Schulz wrote:
> Jan Beulich @ 2021-07-16 09:52 CEST:
>> On 15.07.2021 23:23, Charles-H. Schulz wrote:
>>> Hello,
>>>
>>> I /we /Vates would like to suggest some changes to the policy regarding the
>>> enrollment to the pre-disclosure mailing list of the Xen Security Team.
>>>
>>> We have had some talks with the French national CERT who has a need to be the
>>> recipient of such a list. This national CERT -and in my experience other
>>> national CERTs such as the NIST for instance- is in constant contact with a
>>> large Xen userbase that is mostly made up of large parts of the public sector
>>> as well as critical infrastructure operators belonging to the private
>>> sector. For confidentiality reasons they cannot disclose who uses Xen and
>>> where it is used nor who may be using it internally or within the related
>>> national cybersecurity authority.
>>>
>>> Because of that, their request may not be clear or matching the existing
>>> criteria for inclusion in the mailing list. National CERTs are trusted
>>> actors and have historically been among the very first entities to define,
>>> advocate for and put in practice the very notion of responsible
>>> disclosure. Much of the current practice of Open Source projects in that
>>> regard actually stems from CERTs. As part of their policies and processes
>>> regarding vulnerability disclosure, the notion of confidentiality and
>>> documented, waterfall-like processes of disclosure is play an integral
>>> part of
>>> how they handle informaton and publicity around vulnerability. As a result,
>>> national CERTs (and the French National CERT) do not spread undisclosed
>>> vulnerability without following established and agreed-upon processes. Such
>>> processes include, in our instance, the ones defined and followed by the Xen
>>> Security Team. Compliance with these are the first criteria to earn trust and
>>> respect from the ecosystem and the downstream users. You can see an example
>>> of their work here: https://www.cert.ssi.gouv.fr/
>>>
>>> Part of the mission of the French National CERT is to work with
>>> critical infrastructure providers in securing their IT.
>>> This kind of expertise entails the securing of these information
>>> systems before any unforeseen incident as well as after the incident
>>> (incident remediation).
>>> None of the tasks involved imply the communication of zero-day types
>>> of vulnerabilities or vulnerabilities that are unpublished to the
>>> downstream users.
>>
>> Would you mind shedding some light on the benefits of a national CERT
>> being in the know of unpublished vulnerabilities when they can't share
>> that knowledge with their downstreams, and hence their downstreams -
>> as long as they aren't themselves members of our predisclosure list -
>> would still be zero-dayed at the time of publication of such
>> vulnerabilities? Shouldn't their advice to their downstreams rather be
>> to direct them towards applying for pre-disclosure list membership?
> 
> In practice, most of the downstream users that the CERTs work with are not
> going to subscribe to the Xen pre-disclosure list, nor to any pre-disclosure
> lists of vendors or Open Source Software projects. The downstream users will
> work with CERTs and various cybersecurity service providers (Security
> Operations Centers -SOCs- being a typical example) in order for vulnerability
> discovery, disclosure, patching and later integration of fixes or remediatory
> measures be managed and applied.

It feels to me as if you didn't really answer my question. You restate
what I understood is the current state of things, from your initial mail.
The important aspect "when they can't share that knowledge with their
downstreams" doesn't get discussed at all. All their downstreams would
have to wait not only until public disclosure (instead of patching their
systems - as far as permitted in every individual case - already during
the embargo period), but there'll be an unavoidable further delay,
however small or large. I'm having difficulty seeing how this can be in
everybody's best interest, and hence I can't help suspecting that
information might flow irrespective of this being prohibited except
_among_ members of the predisclosure list.

What I could see is them acting as a proxy for their downstreams, but
this isn't what you've been asking for, and this would also mean much
more of a change to the policy.

> So a national CERT being in the loop of such advanced, upstream vulnerability
> pre-disclosures list is pretty much what a CERT does when it's not publishing
> security advisories of some kind. There are several benefits for a CERT:
> - threat intelligence and analysis: one vulnerability discovered in one
>   source may not be an isolated "incident" - it may be connected to a broader
>   attack made of the exploitation of several vulnerabilities found across
>   different software stacks. This also providers valuable information about the
>   threat landscape and relevance. For instance, Xen having several
>   vulnerability reports is one thing, but what happens if KVM receives a batch
>   of previously unknown vulnerabilities roughly at the same time? For a CERT,
>   that level of information can be very important (sometimes "national
>   security" important)
> 
> - because of a CERT being a nexus of several threat information/intelligence
>   by being as upstream as it can on critical software components, it can then
>   act -not by disclosing or patching yet unpublished vulnerabilities on its
>   own- by setting the effective patching and remediation work on the
>   information systems it is in charge of protecting. In the case of a
>   national CERT, such as the CERT-FR, that would be the French central
>   administration networks and information systems. Essentially it would
>   prioritize the response given the specific level and nature  of threats and the
>   presence of vulnerabilities on the systems (i.e: first patch MS Office,
>   then Apache httpd, then the vulnerability XYZ00123 on Xen as it really
>   affects only a small part of our Xen deployments).
> 
> - last but not least, CERTs act as central vulnerability reports
>   "broadcasters". CERT users/subscribers/clients point to CERTs to receive
>   their daily security watch and alerts. 
> 
>>
>> As to the actual policy - how would you propose to categorize such
>> organizations, i.e. how would a new bullet point in the present
>>
>> "
>> This includes:
>>
>>     Public hosting providers;
>>     Large-scale organisational users of Xen;
>>     Vendors of Xen-based systems;
>>     Distributors of operating systems with Xen support.
>> "
>>
>> look like in your opinion? This is pretty important imo, as it will
>> need to be understood who else might then become eligible.
> 
> I think it's either a very difficult or a very simple question. If I were to
> suggest to simply add a line with "national CERTs" meaning: CERTs that
> operate on behalf of governments for the protection and cybersecurity watch
> of national administration and critical infrastructures" would that be
> accepted? I'm happy with that one. It's really two criteria I'm adding: being
> a CERTs acting wth a clear mandate from a national authority to serve as the
> national computing emergency response team. Not sure how satisfactory that
> is.

So what if some entity acted largely like a "national CERT", but wasn't
called that way? The present items on the list try to use pretty generic
terms, while your suggestion is pretty specific. I'm further afraid that
"a clear mandate from a national authority" may not provide any
justification at all, depending on (often political) view points.

Jan

Re: Suggested changes to the admission policy of the vulnerability pre-disclosure list

[Charles-H. Schulz]

Jan Beulich @ 2021-07-16 17:21 CEST:

> On 16.07.2021 15:13, Charles-H. Schulz wrote:
>> Jan Beulich @ 2021-07-16 09:52 CEST:
>>> On 15.07.2021 23:23, Charles-H. Schulz wrote:
>>>> Hello,
>>>>
>>>> I /we /Vates would like to suggest some changes to the policy regarding the
>>>> enrollment to the pre-disclosure mailing list of the Xen Security Team.
>>>>
>>>> We have had some talks with the French national CERT who has a need to be the
>>>> recipient of such a list. This national CERT -and in my experience other
>>>> national CERTs such as the NIST for instance- is in constant contact with a
>>>> large Xen userbase that is mostly made up of large parts of the public sector
>>>> as well as critical infrastructure operators belonging to the private
>>>> sector. For confidentiality reasons they cannot disclose who uses Xen and
>>>> where it is used nor who may be using it internally or within the related
>>>> national cybersecurity authority.
>>>>
>>>> Because of that, their request may not be clear or matching the existing
>>>> criteria for inclusion in the mailing list. National CERTs are trusted
>>>> actors and have historically been among the very first entities to define,
>>>> advocate for and put in practice the very notion of responsible
>>>> disclosure. Much of the current practice of Open Source projects in that
>>>> regard actually stems from CERTs. As part of their policies and processes
>>>> regarding vulnerability disclosure, the notion of confidentiality and
>>>> documented, waterfall-like processes of disclosure is play an integral
>>>> part of
>>>> how they handle informaton and publicity around vulnerability. As a result,
>>>> national CERTs (and the French National CERT) do not spread undisclosed
>>>> vulnerability without following established and agreed-upon processes. Such
>>>> processes include, in our instance, the ones defined and followed by the Xen
>>>> Security Team. Compliance with these are the first criteria to earn trust and
>>>> respect from the ecosystem and the downstream users. You can see an example
>>>> of their work here: https://www.cert.ssi.gouv.fr/
>>>>
>>>> Part of the mission of the French National CERT is to work with
>>>> critical infrastructure providers in securing their IT.
>>>> This kind of expertise entails the securing of these information
>>>> systems before any unforeseen incident as well as after the incident
>>>> (incident remediation).
>>>> None of the tasks involved imply the communication of zero-day types
>>>> of vulnerabilities or vulnerabilities that are unpublished to the
>>>> downstream users.
>>>
>>> Would you mind shedding some light on the benefits of a national CERT
>>> being in the know of unpublished vulnerabilities when they can't share
>>> that knowledge with their downstreams, and hence their downstreams -
>>> as long as they aren't themselves members of our predisclosure list -
>>> would still be zero-dayed at the time of publication of such
>>> vulnerabilities? Shouldn't their advice to their downstreams rather be
>>> to direct them towards applying for pre-disclosure list membership?
>> 
>> In practice, most of the downstream users that the CERTs work with are not
>> going to subscribe to the Xen pre-disclosure list, nor to any pre-disclosure
>> lists of vendors or Open Source Software projects. The downstream users will
>> work with CERTs and various cybersecurity service providers (Security
>> Operations Centers -SOCs- being a typical example) in order for vulnerability
>> discovery, disclosure, patching and later integration of fixes or remediatory
>> measures be managed and applied.
>
> It feels to me as if you didn't really answer my question. You restate
> what I understood is the current state of things, from your initial mail.
> The important aspect "when they can't share that knowledge with their
> downstreams" doesn't get discussed at all. All their downstreams would
> have to wait not only until public disclosure (instead of patching their
> systems - as far as permitted in every individual case - already during
> the embargo period), but there'll be an unavoidable further delay,
> however small or large. I'm having difficulty seeing how this can be in
> everybody's best interest, and hence I can't help suspecting that
> information might flow irrespective of this being prohibited except
> _among_ members of the predisclosure list.

You seem to suspect dishonest or malevolent intent from CERTs.
It's not a proper base for discussion. Therefore I'm not going to hypothesize
on some sharing of information with downstream users which will actually not
happen, because the behaviour you suspect is not an accepted behaviour,
neither from the CERTs themselves nor by professional actors in charge of responsible
disclosure and software security. 

Having said that, you are right indeed that the downstream users will not
patch their systems before some time, usually because CERTs, service
providers or software vendors will notify them or do the work for them. But
that is how things tend to work unfortunately. CERTs act as their source of
information and prompt them to act. One can find it a bit idiotic, and I also
do think that both public and private sector entities should be much more
proactive when it comes to their security. But that's another discussion. 

>
> What I could see is them acting as a proxy for their downstreams, but
> this isn't what you've been asking for, and this would also mean much
> more of a change to the policy.

They act as a resource center for their downstreams, but the information goes
top down, i.e from the software developer to the downstream, not the
opposite. Also how it entails an even bigger change to the list policy is
unclear to me. 

>
>> So a national CERT being in the loop of such advanced, upstream vulnerability
>> pre-disclosures list is pretty much what a CERT does when it's not publishing
>> security advisories of some kind. There are several benefits for a CERT:
>> - threat intelligence and analysis: one vulnerability discovered in one
>>   source may not be an isolated "incident" - it may be connected to a broader
>>   attack made of the exploitation of several vulnerabilities found across
>>   different software stacks. This also providers valuable information about the
>>   threat landscape and relevance. For instance, Xen having several
>>   vulnerability reports is one thing, but what happens if KVM receives a batch
>>   of previously unknown vulnerabilities roughly at the same time? For a CERT,
>>   that level of information can be very important (sometimes "national
>>   security" important)
>> 
>> - because of a CERT being a nexus of several threat information/intelligence
>>   by being as upstream as it can on critical software components, it can then
>>   act -not by disclosing or patching yet unpublished vulnerabilities on its
>>   own- by setting the effective patching and remediation work on the
>>   information systems it is in charge of protecting. In the case of a
>>   national CERT, such as the CERT-FR, that would be the French central
>>   administration networks and information systems. Essentially it would
>>   prioritize the response given the specific level and nature  of threats and the
>>   presence of vulnerabilities on the systems (i.e: first patch MS Office,
>>   then Apache httpd, then the vulnerability XYZ00123 on Xen as it really
>>   affects only a small part of our Xen deployments).
>> 
>> - last but not least, CERTs act as central vulnerability reports
>>   "broadcasters". CERT users/subscribers/clients point to CERTs to receive
>>   their daily security watch and alerts. 
>> 
>>>
>>> As to the actual policy - how would you propose to categorize such
>>> organizations, i.e. how would a new bullet point in the present
>>>
>>> "
>>> This includes:
>>>
>>>     Public hosting providers;
>>>     Large-scale organisational users of Xen;
>>>     Vendors of Xen-based systems;
>>>     Distributors of operating systems with Xen support.
>>> "
>>>
>>> look like in your opinion? This is pretty important imo, as it will
>>> need to be understood who else might then become eligible.
>> 
>> I think it's either a very difficult or a very simple question. If I were to
>> suggest to simply add a line with "national CERTs" meaning: CERTs that
>> operate on behalf of governments for the protection and cybersecurity watch
>> of national administration and critical infrastructures" would that be
>> accepted? I'm happy with that one. It's really two criteria I'm adding: being
>> a CERTs acting wth a clear mandate from a national authority to serve as the
>> national computing emergency response team. Not sure how satisfactory that
>> is.
>
> So what if some entity acted largely like a "national CERT", but wasn't
> called that way?

The what if question is not a valid one, as you are either recognized as a
national CERT (there may sometimes be more than one) or you're not, by
regulatory approval of some sort.  Nobody else can claim they're a national
CERT.
You can be a private CERT, but that's out of the scope of my request. 

> The present items on the list try to use pretty generic
> terms, while your suggestion is pretty specific.

So how is that a problem in our this specific instance?

> I'm further afraid that
> "a clear mandate from a national authority" may not provide any
> justification at all, depending on (often political) view points.
>

That is factually and legally false. A national CERT, just like a national
cybersecurity authority, is appointed by law or decree in a country and it
does not call for any justification not anything political. It is part of the
administration of the country. In France, CERT-FR is part of ANSSI, itself
part of the National Security and Defense Directorate (SGDSN), acting under
the authority of the Prime Minister. In Germany, CERT-DE belongs to the BMI
(Interior Ministry). I believe in the US CERT-US operates within the NIST or
the DHS, etc. 

All the best,

-- 
Charles-H. Schulz
Chief Strategy Officer - CSO
XCP-ng & Xen Orchestra - Vates solutions

Re: Suggested changes to the admission policy of the vulnerability pre-disclosure list

[Jan Beulich]

On 16.07.2021 22:08, Charles-H. Schulz wrote:
> Jan Beulich @ 2021-07-16 17:21 CEST:
>> On 16.07.2021 15:13, Charles-H. Schulz wrote:
>>> Jan Beulich @ 2021-07-16 09:52 CEST:
>>>> On 15.07.2021 23:23, Charles-H. Schulz wrote:
>>>>> Hello,
>>>>>
>>>>> I /we /Vates would like to suggest some changes to the policy regarding the
>>>>> enrollment to the pre-disclosure mailing list of the Xen Security Team.
>>>>>
>>>>> We have had some talks with the French national CERT who has a need to be the
>>>>> recipient of such a list. This national CERT -and in my experience other
>>>>> national CERTs such as the NIST for instance- is in constant contact with a
>>>>> large Xen userbase that is mostly made up of large parts of the public sector
>>>>> as well as critical infrastructure operators belonging to the private
>>>>> sector. For confidentiality reasons they cannot disclose who uses Xen and
>>>>> where it is used nor who may be using it internally or within the related
>>>>> national cybersecurity authority.
>>>>>
>>>>> Because of that, their request may not be clear or matching the existing
>>>>> criteria for inclusion in the mailing list. National CERTs are trusted
>>>>> actors and have historically been among the very first entities to define,
>>>>> advocate for and put in practice the very notion of responsible
>>>>> disclosure. Much of the current practice of Open Source projects in that
>>>>> regard actually stems from CERTs. As part of their policies and processes
>>>>> regarding vulnerability disclosure, the notion of confidentiality and
>>>>> documented, waterfall-like processes of disclosure is play an integral
>>>>> part of
>>>>> how they handle informaton and publicity around vulnerability. As a result,
>>>>> national CERTs (and the French National CERT) do not spread undisclosed
>>>>> vulnerability without following established and agreed-upon processes. Such
>>>>> processes include, in our instance, the ones defined and followed by the Xen
>>>>> Security Team. Compliance with these are the first criteria to earn trust and
>>>>> respect from the ecosystem and the downstream users. You can see an example
>>>>> of their work here: https://www.cert.ssi.gouv.fr/
>>>>>
>>>>> Part of the mission of the French National CERT is to work with
>>>>> critical infrastructure providers in securing their IT.
>>>>> This kind of expertise entails the securing of these information
>>>>> systems before any unforeseen incident as well as after the incident
>>>>> (incident remediation).
>>>>> None of the tasks involved imply the communication of zero-day types
>>>>> of vulnerabilities or vulnerabilities that are unpublished to the
>>>>> downstream users.
>>>>
>>>> Would you mind shedding some light on the benefits of a national CERT
>>>> being in the know of unpublished vulnerabilities when they can't share
>>>> that knowledge with their downstreams, and hence their downstreams -
>>>> as long as they aren't themselves members of our predisclosure list -
>>>> would still be zero-dayed at the time of publication of such
>>>> vulnerabilities? Shouldn't their advice to their downstreams rather be
>>>> to direct them towards applying for pre-disclosure list membership?
>>>
>>> In practice, most of the downstream users that the CERTs work with are not
>>> going to subscribe to the Xen pre-disclosure list, nor to any pre-disclosure
>>> lists of vendors or Open Source Software projects. The downstream users will
>>> work with CERTs and various cybersecurity service providers (Security
>>> Operations Centers -SOCs- being a typical example) in order for vulnerability
>>> discovery, disclosure, patching and later integration of fixes or remediatory
>>> measures be managed and applied.
>>
>> It feels to me as if you didn't really answer my question. You restate
>> what I understood is the current state of things, from your initial mail.
>> The important aspect "when they can't share that knowledge with their
>> downstreams" doesn't get discussed at all. All their downstreams would
>> have to wait not only until public disclosure (instead of patching their
>> systems - as far as permitted in every individual case - already during
>> the embargo period), but there'll be an unavoidable further delay,
>> however small or large. I'm having difficulty seeing how this can be in
>> everybody's best interest, and hence I can't help suspecting that
>> information might flow irrespective of this being prohibited except
>> _among_ members of the predisclosure list.
> 
> You seem to suspect dishonest or malevolent intent from CERTs.
> It's not a proper base for discussion. Therefore I'm not going to hypothesize
> on some sharing of information with downstream users which will actually not
> happen, because the behaviour you suspect is not an accepted behaviour,
> neither from the CERTs themselves nor by professional actors in charge of responsible
> disclosure and software security. 
> 
> Having said that, you are right indeed that the downstream users will not
> patch their systems before some time, usually because CERTs, service
> providers or software vendors will notify them or do the work for them. But
> that is how things tend to work unfortunately. CERTs act as their source of
> information and prompt them to act. One can find it a bit idiotic, and I also
> do think that both public and private sector entities should be much more
> proactive when it comes to their security. But that's another discussion. 

Well, if it's really (and intentionally) like this, then my suspicion
above would indeed be wrong.

>> What I could see is them acting as a proxy for their downstreams, but
>> this isn't what you've been asking for, and this would also mean much
>> more of a change to the policy.
> 
> They act as a resource center for their downstreams, but the information goes
> top down, i.e from the software developer to the downstream, not the
> opposite. Also how it entails an even bigger change to the list policy is
> unclear to me. 

For things to make sense (as you seem to agree with as per further up),
if their downstreams aren't to subscribe to our (and perhaps other)
pre-disclosure list themselves, the CERTs would need to act as a proxy,
in that they'd be permitted to relay the information before the embargo
ends. I didn't think there would be much of a difficulty seeing that
this would be more of a change to the policy.

>>>> As to the actual policy - how would you propose to categorize such
>>>> organizations, i.e. how would a new bullet point in the present
>>>>
>>>> "
>>>> This includes:
>>>>
>>>>     Public hosting providers;
>>>>     Large-scale organisational users of Xen;
>>>>     Vendors of Xen-based systems;
>>>>     Distributors of operating systems with Xen support.
>>>> "
>>>>
>>>> look like in your opinion? This is pretty important imo, as it will
>>>> need to be understood who else might then become eligible.
>>>
>>> I think it's either a very difficult or a very simple question. If I were to
>>> suggest to simply add a line with "national CERTs" meaning: CERTs that
>>> operate on behalf of governments for the protection and cybersecurity watch
>>> of national administration and critical infrastructures" would that be
>>> accepted? I'm happy with that one. It's really two criteria I'm adding: being
>>> a CERTs acting wth a clear mandate from a national authority to serve as the
>>> national computing emergency response team. Not sure how satisfactory that
>>> is.
>>
>> So what if some entity acted largely like a "national CERT", but wasn't
>> called that way?
> 
> The what if question is not a valid one, as you are either recognized as a
> national CERT (there may sometimes be more than one) or you're not, by
> regulatory approval of some sort.  Nobody else can claim they're a national
> CERT.
> You can be a private CERT, but that's out of the scope of my request. 
> 
>> The present items on the list try to use pretty generic
>> terms, while your suggestion is pretty specific.
> 
> So how is that a problem in our this specific instance?

Why would we exclude private CERTs? I could easily see there being
countries which have no "national CERT" (for a variety of reasons),
with some private / non-government organization jumping in.

>> I'm further afraid that
>> "a clear mandate from a national authority" may not provide any
>> justification at all, depending on (often political) view points.
>>
> 
> That is factually and legally false. A national CERT, just like a national
> cybersecurity authority, is appointed by law or decree in a country and it
> does not call for any justification not anything political. It is part of the
> administration of the country. In France, CERT-FR is part of ANSSI, itself
> part of the National Security and Defense Directorate (SGDSN), acting under
> the authority of the Prime Minister. In Germany, CERT-DE belongs to the BMI
> (Interior Ministry). I believe in the US CERT-US operates within the NIST or
> the DHS, etc. 

There is very much a political aspect in here, imo: "Appointed by
law or decree in a country" can be against law in another country.
Knowledge of vulnerabilities can be used not only to improve
cybersecurity.

Jan

Re: Suggested changes to the admission policy of the vulnerability pre-disclosure list

[Charles-H. Schulz]

Jan Beulich @ 2021-07-19 08:44 CEST:

> On 16.07.2021 22:08, Charles-H. Schulz wrote:
>> Jan Beulich @ 2021-07-16 17:21 CEST:
>>> On 16.07.2021 15:13, Charles-H. Schulz wrote:
>>>> Jan Beulich @ 2021-07-16 09:52 CEST:
>>>>> On 15.07.2021 23:23, Charles-H. Schulz wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I /we /Vates would like to suggest some changes to the policy regarding the
>>>>>> enrollment to the pre-disclosure mailing list of the Xen Security Team.
>>>>>>
>>>>>> We have had some talks with the French national CERT who has a need to be the
>>>>>> recipient of such a list. This national CERT -and in my experience other
>>>>>> national CERTs such as the NIST for instance- is in constant contact with a
>>>>>> large Xen userbase that is mostly made up of large parts of the public sector
>>>>>> as well as critical infrastructure operators belonging to the private
>>>>>> sector. For confidentiality reasons they cannot disclose who uses Xen and
>>>>>> where it is used nor who may be using it internally or within the related
>>>>>> national cybersecurity authority.
>>>>>>
>>>>>> Because of that, their request may not be clear or matching the existing
>>>>>> criteria for inclusion in the mailing list. National CERTs are trusted
>>>>>> actors and have historically been among the very first entities to define,
>>>>>> advocate for and put in practice the very notion of responsible
>>>>>> disclosure. Much of the current practice of Open Source projects in that
>>>>>> regard actually stems from CERTs. As part of their policies and processes
>>>>>> regarding vulnerability disclosure, the notion of confidentiality and
>>>>>> documented, waterfall-like processes of disclosure is play an integral
>>>>>> part of
>>>>>> how they handle informaton and publicity around vulnerability. As a result,
>>>>>> national CERTs (and the French National CERT) do not spread undisclosed
>>>>>> vulnerability without following established and agreed-upon processes. Such
>>>>>> processes include, in our instance, the ones defined and followed by the Xen
>>>>>> Security Team. Compliance with these are the first criteria to earn trust and
>>>>>> respect from the ecosystem and the downstream users. You can see an example
>>>>>> of their work here: https://www.cert.ssi.gouv.fr/
>>>>>>
>>>>>> Part of the mission of the French National CERT is to work with
>>>>>> critical infrastructure providers in securing their IT.
>>>>>> This kind of expertise entails the securing of these information
>>>>>> systems before any unforeseen incident as well as after the incident
>>>>>> (incident remediation).
>>>>>> None of the tasks involved imply the communication of zero-day types
>>>>>> of vulnerabilities or vulnerabilities that are unpublished to the
>>>>>> downstream users.
>>>>>
>>>>> Would you mind shedding some light on the benefits of a national CERT
>>>>> being in the know of unpublished vulnerabilities when they can't share
>>>>> that knowledge with their downstreams, and hence their downstreams -
>>>>> as long as they aren't themselves members of our predisclosure list -
>>>>> would still be zero-dayed at the time of publication of such
>>>>> vulnerabilities? Shouldn't their advice to their downstreams rather be
>>>>> to direct them towards applying for pre-disclosure list membership?
>>>>
>>>> In practice, most of the downstream users that the CERTs work with are not
>>>> going to subscribe to the Xen pre-disclosure list, nor to any pre-disclosure
>>>> lists of vendors or Open Source Software projects. The downstream users will
>>>> work with CERTs and various cybersecurity service providers (Security
>>>> Operations Centers -SOCs- being a typical example) in order for vulnerability
>>>> discovery, disclosure, patching and later integration of fixes or remediatory
>>>> measures be managed and applied.
>>>
>>> It feels to me as if you didn't really answer my question. You restate
>>> what I understood is the current state of things, from your initial mail.
>>> The important aspect "when they can't share that knowledge with their
>>> downstreams" doesn't get discussed at all. All their downstreams would
>>> have to wait not only until public disclosure (instead of patching their
>>> systems - as far as permitted in every individual case - already during
>>> the embargo period), but there'll be an unavoidable further delay,
>>> however small or large. I'm having difficulty seeing how this can be in
>>> everybody's best interest, and hence I can't help suspecting that
>>> information might flow irrespective of this being prohibited except
>>> _among_ members of the predisclosure list.
>> 
>> You seem to suspect dishonest or malevolent intent from CERTs.
>> It's not a proper base for discussion. Therefore I'm not going to hypothesize
>> on some sharing of information with downstream users which will actually not
>> happen, because the behaviour you suspect is not an accepted behaviour,
>> neither from the CERTs themselves nor by professional actors in charge of responsible
>> disclosure and software security. 
>> 
>> Having said that, you are right indeed that the downstream users will not
>> patch their systems before some time, usually because CERTs, service
>> providers or software vendors will notify them or do the work for them. But
>> that is how things tend to work unfortunately. CERTs act as their source of
>> information and prompt them to act. One can find it a bit idiotic, and I also
>> do think that both public and private sector entities should be much more
>> proactive when it comes to their security. But that's another discussion. 
>
> Well, if it's really (and intentionally) like this, then my suspicion
> above would indeed be wrong.
>
>>> What I could see is them acting as a proxy for their downstreams, but
>>> this isn't what you've been asking for, and this would also mean much
>>> more of a change to the policy.
>> 
>> They act as a resource center for their downstreams, but the information goes
>> top down, i.e from the software developer to the downstream, not the
>> opposite. Also how it entails an even bigger change to the list policy is
>> unclear to me. 
>
> For things to make sense (as you seem to agree with as per further up),
> if their downstreams aren't to subscribe to our (and perhaps other)
> pre-disclosure list themselves, the CERTs would need to act as a proxy,
> in that they'd be permitted to relay the information before the embargo
> ends. I didn't think there would be much of a difficulty seeing that
> this would be more of a change to the policy.

Indeed, because you assume that CERTs will communicate information before
they are public. But they don't work that way in that they act as the legal
and actual hub for the public information and listing of vulnerabilities
reports (CVEs etc.) What they do before the end of the embargo date I already
explained, and that specifically does not entail sharing the information with
downstream users. So to me there is no big change of policy - this is the
highway patrol sharing the license plate numbers of criminals or suspects
with the city police. 

>
>>>>> As to the actual policy - how would you propose to categorize such
>>>>> organizations, i.e. how would a new bullet point in the present
>>>>>
>>>>> "
>>>>> This includes:
>>>>>
>>>>>     Public hosting providers;
>>>>>     Large-scale organisational users of Xen;
>>>>>     Vendors of Xen-based systems;
>>>>>     Distributors of operating systems with Xen support.
>>>>> "
>>>>>
>>>>> look like in your opinion? This is pretty important imo, as it will
>>>>> need to be understood who else might then become eligible.
>>>>
>>>> I think it's either a very difficult or a very simple question. If I were to
>>>> suggest to simply add a line with "national CERTs" meaning: CERTs that
>>>> operate on behalf of governments for the protection and cybersecurity watch
>>>> of national administration and critical infrastructures" would that be
>>>> accepted? I'm happy with that one. It's really two criteria I'm adding: being
>>>> a CERTs acting wth a clear mandate from a national authority to serve as the
>>>> national computing emergency response team. Not sure how satisfactory that
>>>> is.
>>>
>>> So what if some entity acted largely like a "national CERT", but wasn't
>>> called that way?
>> 
>> The what if question is not a valid one, as you are either recognized as a
>> national CERT (there may sometimes be more than one) or you're not, by
>> regulatory approval of some sort.  Nobody else can claim they're a national
>> CERT.
>> You can be a private CERT, but that's out of the scope of my request. 
>> 
>>> The present items on the list try to use pretty generic
>>> terms, while your suggestion is pretty specific.
>> 
>> So how is that a problem in our this specific instance?
>
> Why would we exclude private CERTs? I could easily see there being
> countries which have no "national CERT" (for a variety of reasons),
> with some private / non-government organization jumping in.
>

This is a good point I'm not making :)
My request is solely about national CERTs, I do not feel that I have enough
standing here requesting that private CERTs be added to the list, although
I'm sure there's a point to be made here as well.

>>> I'm further afraid that
>>> "a clear mandate from a national authority" may not provide any
>>> justification at all, depending on (often political) view points.
>>>
>> 
>> That is factually and legally false. A national CERT, just like a national
>> cybersecurity authority, is appointed by law or decree in a country and it
>> does not call for any justification not anything political. It is part of the
>> administration of the country. In France, CERT-FR is part of ANSSI, itself
>> part of the National Security and Defense Directorate (SGDSN), acting under
>> the authority of the Prime Minister. In Germany, CERT-DE belongs to the BMI
>> (Interior Ministry). I believe in the US CERT-US operates within the NIST or
>> the DHS, etc. 
>
> There is very much a political aspect in here, imo: "Appointed by
> law or decree in a country" can be against law in another country.
> Knowledge of vulnerabilities can be used not only to improve
> cybersecurity.
>

The fact that one national law is contrary to another national law has no
bearing on the Xen Security Team I think. My point was that there is nothing
political in understanding that national CERTs are established, chartered,
regular actors whose primary function is establishing trust and improving
cybersecurity. 

What you're alluding to are behaviours we are all well aware of, but in
practice you will not find those in national CERTs, which are public entities
with a public service mission acting in public in routine and emergency
contexts. Any director of a national CERT can stand up in front of the
Parliament of his/her coutry and clearly explain what they do. It's not
necessarily the case for the other actors you mention, who will have a large
part of their activities classified. So I would say this is a case for
comparing the CIA and the NYC Fire Department. 

All the best,
-- 
Charles-H. Schulz
Chief Strategy Officer - CSO
XCP-ng & Xen Orchestra - Vates solutions

Re: Suggested changes to the admission policy of the vulnerability pre-disclosure list

[George Dunlap]

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

On Mon, Jul 19, 2021 at 9:49 AM Charles-H. Schulz <charles.schulz@vates.fr>
wrote:

>
> Jan Beulich @ 2021-07-19 08:44 CEST:
>
> >>
> >> They act as a resource center for their downstreams, but the
> information goes
> >> top down, i.e from the software developer to the downstream, not the
> >> opposite. Also how it entails an even bigger change to the list policy
> is
> >> unclear to me.
> >
> > For things to make sense (as you seem to agree with as per further up),
> > if their downstreams aren't to subscribe to our (and perhaps other)
> > pre-disclosure list themselves, the CERTs would need to act as a proxy,
> > in that they'd be permitted to relay the information before the embargo
> > ends. I didn't think there would be much of a difficulty seeing that
> > this would be more of a change to the policy.
>
> Indeed, because you assume that CERTs will communicate information before
> they are public. But they don't work that way in that they act as the legal
> and actual hub for the public information and listing of vulnerabilities
> reports (CVEs etc.) What they do before the end of the embargo date I
> already
> explained, and that specifically does not entail sharing the information
> with
> downstream users. So to me there is no big change of policy - this is the
> highway patrol sharing the license plate numbers of criminals or suspects
> with the city police.
>

Nonetheless, you still haven't made a clear case why being informed of the
vulnerabilities *under embargo* is necessary.  Anyone can sign up to the
xen-announce mailing list and receive notifications of XSAs at the moment
the embargo lifts.  We advertise *that new advisories are coming out* on
the main XSA webpage [1] and in a machine-readable JSON file [2] as soon as
the predisclosure happens.  (There are also libraries [3] to consume the
JSON file, and an example program [4] which could be run in a cron job to
alert someone to upcoming public XSA disclosures.) The delta between the
predisclosure and the public disclosure is typically two weeks.

Someone could argue that all of the activities you describe -- looking for
larger patterns of vulnerabilities, acting as a clearinghouse /
notification channel / advisory system for downstreams, etc -- could be
done by observing the public disclosures, particularly if suitable people
were alerted to upcoming public disclosures (and thus ready to process them
as soon as they come out).  What is needed is to make the case that this is
insufficient -- that having the extra two weeks to process things before
the public disclosure will be of material benefit in those activities.

(Hopefully it should be clear that I'm inviting you to make such a case.)

[1] https://xenbits.xenproject.org/xsa/
[2] https://xenbits.xenproject.org/xsa/xsa.json
[3]
https://gitlab.com/xen-project/people/gdunlap/go-xenlib/-/tree/master/xsalib
[4]
https://gitlab.com/xen-project/people/gdunlap/go-xenlib/-/tree/master/scripts/xsa-alert


> >> The what if question is not a valid one, as you are either recognized
> as a
> >> national CERT (there may sometimes be more than one) or you're not, by
> >> regulatory approval of some sort.  Nobody else can claim they're a
> national
> >> CERT.
> >> You can be a private CERT, but that's out of the scope of my request.
> >>
> >>> The present items on the list try to use pretty generic
> >>> terms, while your suggestion is pretty specific.
> >>
> >> So how is that a problem in our this specific instance?
> >
> > Why would we exclude private CERTs? I could easily see there being
> > countries which have no "national CERT" (for a variety of reasons),
> > with some private / non-government organization jumping in.
> >
>
> This is a good point I'm not making :)
> My request is solely about national CERTs, I do not feel that I have enough
> standing here requesting that private CERTs be added to the list, although
> I'm sure there's a point to be made here as well.
>

Jan, I think if you think it's better to include "private CERTs" (do such
things exist?), then it should be up to you (or someone else in favor of
such a thing) to craft the criteria for inclusion.  I personally think
limiting ourselves to national CERTs to begin with is fine.

In any case, what's needed to move things forward (absent further
discussion) is:

1. Specific proposed changes to the security policy to be hammered out

2. Someone to hold a project-wide vote, in accordance with the XenProject
Governance Document.

Normally #2 would be me, but today is my last day until January.

 -George

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

Re: Suggested changes to the admission policy of the vulnerability pre-disclosure list

[Charles-H. Schulz]

Hello Georges,

Le vendredi 23 juillet 2021 à 14:09 +0100, George Dunlap a écrit :
>
>
> On Mon, Jul 19, 2021 at 9:49 AM Charles-H. Schulz
> <charles.schulz@vates.fr> wrote:
> >
> > Jan Beulich @ 2021-07-19 08:44 CEST:
> >
> > > >
> > > > They act as a resource center for their downstreams, but the
> > information goes
> > > > top down, i.e from the software developer to the downstream, not
> > the
> > > > opposite. Also how it entails an even bigger change to the list
> > policy is
> > > > unclear to me.
> > >
> > > For things to make sense (as you seem to agree with as per further
> > up),
> > > if their downstreams aren't to subscribe to our (and perhaps other)
> > > pre-disclosure list themselves, the CERTs would need to act as a
> > proxy,
> > > in that they'd be permitted to relay the information before the
> > embargo
> > > ends. I didn't think there would be much of a difficulty seeing
> > that
> > > this would be more of a change to the policy.
> >
> > Indeed, because you assume that CERTs will communicate information
> > before
> > they are public. But they don't work that way in that they act as the
> > legal
> > and actual hub for the public information and listing of
> > vulnerabilities
> > reports (CVEs etc.) What they do before the end of the embargo date I
> > already
> > explained, and that specifically does not entail sharing the
> > information with
> > downstream users. So to me there is no big change of policy - this is
> > the
> > highway patrol sharing the license plate numbers of criminals or
> > suspects
> > with the city police.
> >
>
>
> Nonetheless, you still haven't made a clear case why being informed of
> the vulnerabilities *under embargo* is necessary.  Anyone can sign up
> to the xen-announce mailing list and receive notifications of XSAs at
> the moment the embargo lifts.  We advertise *that new advisories are
> coming out* on the main XSA webpage [1] and in a machine-readable JSON
> file [2] as soon as the predisclosure happens.  (There are also
> libraries [3] to consume the JSON file, and an example program [4]
> which could be run in a cron job to alert someone to upcoming public
> XSA disclosures.) The delta between the predisclosure and the public
> disclosure is typically two weeks.
>
> Someone could argue that all of the activities you describe -- looking
> for larger patterns of vulnerabilities, acting as a clearinghouse /
> notification channel / advisory system for downstreams, etc -- could be
> done by observing the public disclosures, particularly if suitable
> people were alerted to upcoming public disclosures (and thus ready to
> process them as soon as they come out).  What is needed is to make the
> case that this is insufficient -- that having the extra two weeks to
> process things before the public disclosure will be of material benefit
> in those activities.
>
> (Hopefully it should be clear that I'm inviting you to make such a
> case.)


I had highlighted two reasons. Quoting myself:

"So a national CERT being in the loop of such advanced, upstream
vulnerability pre-disclosures list is pretty much what a CERT does when
it's not publishing security advisories of some kind. There are several
benefits for a CERT:
- threat intelligence and analysis: one vulnerability discovered in one
  source may not be an isolated "incident" - it may be connected to a
broader attack made of the exploitation of several vulnerabilities
found across
  different software stacks. This also providers valuable information
about the
  threat landscape and relevance. For instance, Xen having several
  vulnerability reports is one thing, but what happens if KVM receives
a batch
  of previously unknown vulnerabilities roughly at the same time? For a
CERT,
  that level of information can be very important (sometimes "national
  security" important)

- because of a CERT being a nexus of several threat
information/intelligence
  by being as upstream as it can on critical software components, it
can then
  act -not by disclosing or patching yet unpublished vulnerabilities on
its
  own- by setting the effective patching and remediation work on the
  information systems it is in charge of protecting. In the case of a
  national CERT, such as the CERT-FR, that would be the French central
  administration networks and information systems. Essentially it would
  prioritize the response given the specific level and nature  of
threats and the
  presence of vulnerabilities on the systems (i.e: first patch MS
Office,
  then Apache httpd, then the vulnerability XYZ00123 on Xen as it
really
  affects only a small part of our Xen deployments)."

To this, I add a third, very specific one: CERT-FR is ultimately in
charge of protecting a set of governmental secure systems relying on
Xen.

I hope this is clearer now.



>
> [1] https://xenbits.xenproject.org/xsa/
> [2] https://xenbits.xenproject.org/xsa/xsa.json
> [3]
> https://gitlab.com/xen-project/people/gdunlap/go-xenlib/-/tree/master/xsalib
> [4]
> https://gitlab.com/xen-project/people/gdunlap/go-xenlib/-/tree/master/scripts/xsa-alert
>  
> > > > The what if question is not a valid one, as you are either
> > recognized as a
> > > > national CERT (there may sometimes be more than one) or you're
> > not, by
> > > > regulatory approval of some sort.  Nobody else can claim
> > > > they're a
> > national
> > > > CERT.
> > > > You can be a private CERT, but that's out of the scope of my
> > request.
> > > >
> > > > > The present items on the list try to use pretty generic
> > > > > terms, while your suggestion is pretty specific.
> > > >
> > > > So how is that a problem in our this specific instance?
> > >
> > > Why would we exclude private CERTs? I could easily see there
> > > being
> > > countries which have no "national CERT" (for a variety of
> > > reasons),
> > > with some private / non-government organization jumping in.
> > >
> >
> > This is a good point I'm not making :)
> > My request is solely about national CERTs, I do not feel that I
> > have
> > enough
> > standing here requesting that private CERTs be added to the list,
> > although
> > I'm sure there's a point to be made here as well.
> >
>
>
> Jan, I think if you think it's better to include "private CERTs" (do
> such things exist?), then it should be up to you (or someone else in
> favor of such a thing) to craft the criteria for inclusion.  I
> personally think limiting ourselves to national CERTs to begin with
> is fine.
>
> In any case, what's needed to move things forward (absent further
> discussion) is:
>
> 1. Specific proposed changes to the security policy to be hammered
> out
>
> 2. Someone to hold a project-wide vote, in accordance with the
> XenProject Governance Document.
>
> Normally #2 would be me, but today is my last day until January.

Thank you. I don't think we're in a rush but if we can do this before
January it's perhaps better.


Best regards,

--
Charles-H. Schulz
Chief Strategy Officer- CSO
XCP-ng & Xen Orchestra - Vates solutions