Although it was not the result of a security breach or other directed attack, I can provide this bugzilla bug <https://bugzilla.mozilla.org/show_bug.cgi?id=1742704> as an example of what an embargoed incident report followed by public disclosure has looked like in the past.
Aaron On Thu, May 23, 2024 at 10:59 AM 'Amir Omidi (aaomidi)' via [email protected] <[email protected]> wrote: > Thanks. I guess this question then is aimed at Chunghwa Telecom to let us > know if what's been reported has had any impact on their CA systems. > > On Thursday, May 23, 2024 at 1:07:39 PM UTC-4 Ben Wilson wrote: > >> Amir, >> To answer the last question first, Chunghwa Telecom did not disclose this >> recent attack, but I don't think we have sufficient information from the >> article to determine the effects of the breach on the CA operations. So >> without more information, it might be premature to answer the question, "Is >> a security incident like the one I posted above considered an instance of a >> CA "failing to comply"?" >> The process envisioned by the policy and guidance does contemplate that >> these disclosures would be in a secure bug (to which Mozilla would grant >> other root programs access). It also contemplates that another, public bug >> would need to be created, using the incident-reporting template (including >> a description of the CA's incident response). Finally, because this is a >> new process, we do not yet have any experiences to share or to use in >> evaluating the success or shortcomings of the requirement. >> Ben >> >> On Thu, May 23, 2024 at 9:54 AM 'Amir Omidi (aaomidi)' via >> [email protected] <[email protected]> wrote: >> >>> Hey folks, >>> >>> I am bringing this up because of: >>> https://www.darkreading.com/cyberattacks-data-breaches/taiwan-telco-breached-data-sold-on-dark-web >>> >>> (I've marked my questions in bold) >>> >>> I'm mainly basing this discussion around: >>> https://wiki.mozilla.org/CA/Vulnerability_Disclosure. I want to >>> understand what the intent of some of the wording in this is, and how it >>> applies to CAs. >>> >>> In that wiki, we see: >>> >>> > Vulnerabilities/incidents that may “significantly impact the >>> confidentiality, integrity, or availability” of a CA's internal systems, >>> regardless of direct impact on certificate issuance, must be reported if >>> they pose ongoing risk to the overall integrity and security of CA >>> operations. This includes significant impact not just to issuing systems, >>> but also to network and server security, internal software, and the >>> availability and reliability of certificate status services, such as CRLs >>> and OCSP. >>> >>> What is Mozilla's intent by the phrase "must be reported if they pose >>> ongoing risk to the overall integrity and security of CA operations." >>> >>> More specifically: >>> >>> 1. *"Disclosed" to whom? Public? Just Mozilla?* >>> 2. *What does "if they pose an ongoing risk" mean? If its a one-off >>> attack, does that mean it does not need to be disclosed?* >>> >>> I'm also unsure about trusting CAs to determine the significance of such >>> an attack. We've seen recently that a few CAs have really jumped to making >>> claims such as "this incident has no security impact" before doing any >>> proper RCA or even understanding the extent of the incident. *Has >>> Mozilla found any issues with leaving the determination up to CAs in the >>> past?* >>> >>> More broadly, how does this wiki work when read in conjunction with the >>> Mozilla >>> Root Store Policy >>> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/> >>> >>> Specifically, section 2.4: >>> >>> > When a CA operator fails to comply with any requirement of this policy >>> - whether it be a misissuance, a procedural or operational issue, or any >>> other variety of non-compliance - the event is classified as an incident >>> and MUST be reported to Mozilla as soon as the CA operator is made aware. >>> >>> *Is a security incident like the one I posted above considered an >>> instance of a CA "failing to comply"?* >>> >>> In 2.4.1 we see: >>> >>> > Additionally, and not in lieu of the requirement to publicly report >>> incidents as outlined above, a CA Operator MUST disclose a serious >>> vulnerability or security incident in Bugzilla >>> <https://bugzilla.mozilla.org> as a secure bug >>> <https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program> >>> in accordance with guidance found on the Vulnerability Disclosure wiki >>> page <https://wiki.mozilla.org/CA/Vulnerability_Disclosure>. >>> >>> From my reading here, this means that all security vulnerabilities are >>> being disclosed privately to Mozilla. I guess this *kind of* makes >>> sense here. >>> >>> *Would Mozilla be open to having a limited cooling-off period where >>> these secure bugs stay private, but after that period the information >>> becomes public*? >>> >>> My justification for asking this is: >>> >>> - Other CAs can and should learn from how a CA responded to a >>> security incident. >>> - There may be commonalities in attack patterns that these incidents >>> being public can help surface. >>> - It reassures the community that these incidents are being taken >>> seriously by allowing third parties to also verify and validate the >>> incident response and mitigation items. >>> >>> >>> Beyond this, *I'd also be interested in hearing if Chunghwa Telecom has >>> disclosed the impact of this recent attack on their systems (if any) to >>> Mozilla and the other root programs.* >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b9fa92df-2d48-4740-988c-a147285e181dn%40mozilla.org >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b9fa92df-2d48-4740-988c-a147285e181dn%40mozilla.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/0c5cc051-b8a8-4fe3-b959-abbbbebeab4fn%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/0c5cc051-b8a8-4fe3-b959-abbbbebeab4fn%40mozilla.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErdJ_N5QATQu1s%2BZKPG3w989N07shFr7YS3aB8_UhQAiPw%40mail.gmail.com.
