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

[Jan Beulich <jbeulich@xxxxxxxx>]

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