[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: Fri, 16 Jul 2021 09:52:52 +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=pMwtzzVfENFIeyVxHbh8rDEGhkNjoKOCi0g9iVF0DMQ=; b=oABIC9Sfksk5hcDO0QAUL3Nh6O9k65qm8KtDH/sKDQoszRMmfTQQqI4KgNefoM2+qM23OekaAT/9QRsrmKI3lhz0i/8yF+bWrgxKU/e2BmjSEnPwSQ88cZUR4w9yedfUNG8SbbcD8fV3d0NGk9y/SRIeaRDyOyu396ExEmxWhiKq4PH0RRp0jLXGtyFgbqagHhjKg9lt9k2RTEuDcr1UHW18rugR06PTjoUq0WJtCEJQrV0fx7mb2sEbKFtVbj1HrtJyrHSI1rFVAaBb4CXY0yP7ShmQDJarBBpauaQEZ6MeKyFqJgYu/jatlO8e4w3HN7+1mcw2q2w/SqyDRIvv4w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q/zXJFT2nhe3DH7k1KmN9wyXtlBofjhZdlOwQh4U+xcYxgTjN5P5oA1LdS39hl0yrX4MoOAmqyAzu9W1GxCcd1fe4xnkoJHQu+WEFCOhVpj0B3YNO6M6uM2jHKrh4dB85X0lQM7j3KDrnp2YM7kGwKJ0if5+6BF3HxycnYn7JJNljx6iPUScU6IcwIdgwXRsbfNalqG/vTKgh2av1g+f79v3gpC6erLzxbPku21aH9An397B/Ez9UJqTP+GTWLnxnvnLgJy7xl8o/EpQZBh3GXneODDy3hJKNZpmNLJRhaXYYDisKKIUcZPqlPW27eFbK8pj/uZIMKFG/E9eseQG2w==
  • 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: Fri, 16 Jul 2021 07:53:00 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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




 


Rackspace

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