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/CA%2B1gtabNRQpNHpfZR7Rwrqv2dknp3A6eodFzd1%2BVubd1Yn8MHQ%40mail.gmail.com.
