Add Requirements for Reporting CA Security Incidents

[BenWilson-Mozilla]

Currently, MRSP section 7 says “Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.” MRSP section 2.4 discusses an "incident" as "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”. Also see https://wiki.mozilla.org/CA/Responding_To_An_Incident

The MRSP clearly lacks guidance on how CA operators should report attacks and other kinds of security incidents. There are at least three scenarios that can be explored in drafting new reporting requirements for security incidents:

1. A DDOS attack that is operationally disruptive to the company but does not affect certificate issuance.
2. A compromise of a CA's internal systems by an attack that does not affect the company's certificate issuance. This would likely include ransomware because such an attack typically involves compromise of non-public assets.
3. A compromise of a CA's internal systems by an attacker, in which the attacker does somehow affect certificate issuance.

Scenario 1 should not have to be reported. Scenario 3 definitely should be reported. There is a gray area for Scenario 2 that we need to address. Scenario 2 poses risks to Mozilla users in two distinct ways. First, the attacker compromised internal systems and might still be lurking in those systems. That is a reasonable expectation when you have such a compromise. If that is the case, the attacker can still move laterally and pose a direct risk to the certificate issuance. Second, even if the attacker is no longer in the system, the fact of the internal compromise can still potentially tell you something about the security practices of the company and about the risk to users if lax security practices are exploited in the future.

Also, ongoing criminal investigation and other circumstances related to incident response may complicate the drafting of reporting requirements for security incidents. This will need further consideration.

[RufusJWB]

While understanding and sharing the basic target of this issue, I'd like to point out, that there are many CAs which are operated by large organizations, and we need to find a wording which makes clear that not every single cyber security incident in an unrelated business department needs to be reported to Mozilla.

[BenWilson-Mozilla]

Besides defining the types of incidents that fit into this category, we would need to develop a process that collects the information in a confidential manner and, possibly, reports the results (sub-types, root causes, threat actors, etc.) anonymously, which will enable a process that provides valuable security-related information in a way that other CAs can learn from. This would also need to protect the interest of our users, i.e. where public distrust is being considered or when public distrust is the action that needs to be taken.

[BenWilson-Mozilla]

Article 23 of the NIS2 Directive provides some language that might be helpful. It defines a "significant incident" as one that "has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned" or "has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage." It also has reporting requirements - "without undue delay and in any event within 24 hours of becoming aware of the significant incident, an early warning, which, where applicable, shall indicate whether the significant incident is suspected of being caused by unlawful or malicious acts."