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
