[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Charles-H. Schulz" <charles.schulz@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 19 Jul 2021 08:44:36 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JKQ7LFynAitHLMqldOmFq2bwmJP/pDKzRdeQ2CVHO9U=; b=kS8R+Jlaf7PbGiqxNtR6DJaxZI83Wg/Er1HOWzq/br7eSG/Ut8I4ArU3qmS/cBfl8aZukITMzY26hiKekrFCueee+X65ePzYZzJ01D7/+6iTodnLlphuGRCvMQmoaCpPokZhSnVl+f3T31cot1muL9FiyLiP4N1kZEYYoPbe79iU4T1r1XJn0jV6VXkR7rAlbMVHZZq3WKDvmh+6kXmg9+6iVtdLgsowGbhl3VsXslPBK1Tz/FHF9raBAdayabfsL6p6AwNknafUsScHDsrsqy4WTzcOxsdvYb5x7h/1tdTzDElDHPHFCNquctHn3o9Icq0FRI2U8XTydrExawvi8g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bTynxhsd4PFmSjsVQQ+1RlQJOqWRUD2MsBkiyCgqwkYW7ReNVWPEX1ks43Exe2V2bXbtS3wHg7snyT2yI46ULKU80vkpZagaHNiJo4FC/WDfL9vPkMzYyOEtkvh77Zsiy4t28iR0IoE8kax30bORkUi/9ZldDd3M1PpLkyW5e4UIE/h5O7gsvsaAWtPuyUr7kv1+5RpOqg72HKMBw51OwkVlf5FWasqstx1/ypGA5wxcrFc9lZO56O7pmmXnyXk0H/WSk6OlfRLcEj2GBYC3FXlDY4egyJFNJrZFHnFqUwc27SpYwFxU4vVjWRcRkwpwIPMbcJs0MaWh9PATbb4thQ==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 19 Jul 2021 06:45:09 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.