To bring this discussion back up what is the required impact for disclosure? To move the discussion away from Chunghwa Telecom, there also was Lockbit ransomware deployed at Entrust in June '22 and at least 400GB+ data exfiltrated. We have not had a public report of what data relevant to CA operations was obtained. Although correct me if I am wrong I've not delved that deeply into the subject.
Keeping to the technical level and leaving the minefield of personal information to the side for this discussion... What aspects of the CA operation must be impacted for this to be a notifiable event? Presumably anything directly impacting the HSMs, certificate's private keys, or issuance. How many steps removed from that process is fine? Moving to indirect security aspects, would this also apply to pentest reports on the CA infrastructure? I'd presume there's also a lot of information generated in Webtrust or ETSI audits that would also be material to the security environment. Given this is a recent real world scenario I think it would be a good example to work through. On Saturday, May 25, 2024 at 11:25:09 AM UTC+1 Li-Chun CHEN wrote: > Our company's CA system is independent of telecommunications system. There > is no impact on Chunghwa Telecom's CA System related to that data breach > news. Chunghwa Telecom will continue to strengthen the system & network > security control of the CA system to ensure data security. Thank you. > > Li-Chun Chen > Chunghwa Telecom > > > Amir Omidi (aaomidi) 在 2024年5月24日 星期五凌晨1:59:33 [UTC+8] 的信中寫道： > > 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/91c8c4c7-e377-4f73-b14a-3f37e98de330n%40mozilla.org.
