CA/Vulnerability Disclosure
Contents
- 1 Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store
Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store
Purpose
To provide Mozilla with:
- Information about security compromises that require action from Mozilla;
- Security-sensitive information that needs to be shared with Mozilla.
Generally, a Security Vulnerability is a potential weak point that could lead to a security incident if exploited by an attacker, while a Security Incident is any event, breach, or occurrence that poses a threat to the confidentiality, integrity, or availability of a CA Operator’s information assets or computer systems. A Reportable Vulnerability is either a security vulnerability or a security incident that has the potential of having a serious adverse effect on the trustworthiness of certificates. (Not every vulnerability or cybersecurity incident within a large organization's unrelated business departments needs to be reported. However, CA Operators still need to account for the risk that advanced persistent threats and lateral movements by attackers within the CA Operator's broader infrastructure might affect CA operations.)
A CA Operator MUST initially notify Mozilla about a Reportable Vulnerability as soon as possible and no later than 24 hours of internal identification or notification by an external party.
Please be sure to read all material provided below for guidance in assessing and reporting serious vulnerabilities and security incidents to Mozilla.
How to Disclose a Reportable Vulnerability
The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a public-facing Incident Report, as required by section 2.4 of Mozilla’s Root Store Policy.
Reportable Vulnerabilities (serious vulnerabilities and security incidents) must be reported in Bugzilla:
or
https://bugzilla.mozilla.org/enter_bug.cgi
Product: CA Program
Component: CA Security Vulnerability
Make sure you check the box “CA Program Security” under “Only users in all of the selected groups can view this bug”.
Types of Vulnerabilities/Incidents to be disclosed
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. The determination of “significance” is made by the CA Operator based on industry best practices and the guidance below, particularly that guidance found under the heading “Determining Significance”.
Security Incidents include the following:
- Successful unauthorized accesses, acquisitions, disclosures, or thefts of sensitive data or CA equipment involving the CA's systems, infrastructure, networks, applications, or sensitive information (private keys, user credentials, or personally identifiable information).
- Malware infections, ransomware, or other data integrity issues that irrecoverably damage or compromise sensitive CA data.
- Confirmed advanced persistent threats that attempt to compromise the CA's infrastructure, systems, or the reliability or validity of certificates.
The following are NOT ordinarily considered to be Reportable Vulnerabilities:
- Minor security policy violations: Non-malicious violations of internal security policies by employees that are promptly addressed and do not result in unauthorized access or compromise of critical systems or infrastructure.
- Non-Critical Network Intrusion Attempts: Failed attempts to gain unauthorized access to the network, systems, or infrastructure, where there is no evidence of successful compromise or impact on critical operations.
- Low-Level Phishing Attacks or Minor Social Engineering Attempts: Isolated phishing attempts or low-impact social engineering attempts targeting individual employees that are detected and prevented before any successful compromise or unauthorized access to sensitive systems or infrastructure.
- Low-Impact Malware Infections: Instances of malware infections on non-critical systems or endpoints within the network that do not lead to unauthorized access, data breaches, or compromise of private keys or other sensitive information.
- Temporary Network or System Performance Issues and Low-Scale Denial-of-Service (DoS) Attacks: Transient or short-term disruptions, or limited or unsuccessful DoS attacks that (a) degrade performance of non-critical systems, (b) do not compromise critical systems or cause significant service disruptions, (c) minimally impact the CA's operations, or (d) do not impact the integrity or availability of certificate issuance or certificate status services.
- Non-Critical System Misconfigurations: Minor misconfigurations or deviations from recommended security practices on non-critical systems or infrastructure that do not directly impact certificate issuance or pose significant risks to the CA's operations.
- Minor Reconnaissance: A low-level reconnaissance attempt or scanning activity that doesn't result in any compromise or breach of sensitive information.
Vulnerability/Incident Response Expectations
We expect CA Operators to implement their security vulnerability/incident response plan/playbook in accordance with industry best practices. Tasks that should be performed include, but are not limited to:
- Evidence gathering and forensic analysis
- Containment
- Determining vulnerability/incident significance
- Notification of root store operators and other important stakeholders
- System restoration and system integrity
- Root cause analysis
- Security hardening with patches, updates, or configuration changes
- Ongoing remediation
For additional guidance, see sources such as ENISA, CIS Security, CERT.EU, NIST, CISA.gov and ISO/IEC 27035-1:2023.
Determining Significance
Factors to consider in determining the significance or severity of a vulnerability/incident should include:
- the scope and scale of the vulnerability/incident and the impact on CA operations and the CA's ability to maintain operations, business continuity, and continuous services to customers;
- number and type(s) of certificates affected—some certificates may be more critical or sensitive than others, such as those used for high-value transactions, government entities, or critical infrastructure;
- duration (e.g. the date and time when the vulnerability/incident began and when it ended);
- potential harm or impact on certificate holders, relying parties, and others (this includes the potential disruption to their operations, loss of trust, and any financial or legal consequences they may face);
- potential impact of this type of vulnerability/incident on the broader CA industry and the web PKI;
- nature of the vulnerability/incident (e.g. targeted attack, systemic vulnerability, or human error);
- sensitivity of the information threatened;
- potential identity of threat actors (state-sponsored actor, organized crime, or some other highly sophisticated threat actor); and
- escalation potential (assess the likelihood of further escalation, such as through the exploitation of additional vulnerabilities, lateral movement within the network, or the compromise of more critical systems or data).
Additional guidance can also be found in various publications from ENISA, NIST, the Canadian Centre for Cybersecurity, and academia.
Reportable Vulnerability Disclosure Contents
Reportable Vulnerability disclosures must be comprehensive, accurate, transparent, and provide sufficient information to assist Mozilla in determining whether Mozilla needs to take action, such as adding certificates to OneCRL, and whether the CA Operator appropriately determined the severity and the response. Below is a list of essential information that a vulnerability disclosure should contain.
Concise Summary
Provide a concise summary of the vulnerability/incident, including the date and time of discovery, how it was discovered, the nature of the vulnerability/incident, and its potential impact on the CA's infrastructure, systems, and the trustworthiness of certificates.
Vulnerability/Incident Details
- Timeline - A date-and-time-stamped sequence of all relevant events, including events before the vulnerability/incident became known, such as when something changed or was introduced, the initial compromise, lateral movement (if applicable), and actions taken by the CA during and after the discovery of the vulnerability/incident.
- Type and Detailed Description, including the duration of the vulnerability/incident, identity of threat actors, nature of the compromise, and the specific systems, infrastructure, or processes affected.
- Root Cause(s) - Identify the root cause(s) or contributing factors that led to the vulnerability/incident and how they were not previously discovered. Note that the description of root cause(s) does not need to be duplicated here if it can be fully provided in the public-facing Incident Report.
Severity / Impact Assessment
Summarize the following:
- the potential impact of the vulnerability/incident on the CA's operations, systems, certificate issuance, and the trustworthiness of certificates;
- number and type(s) of certificates affected, if applicable;
- the potential impact on certificate holders, relying parties, and other stakeholders; and
- the escalation potential.
Response and Mitigation
- State recommended actions for Mozilla, such as adding a certificate to OneCRL, or distrusting a root certificate after a specified date.
- Summarize the immediate actions taken to contain and mitigate the effects of the vulnerability/incident, including isolation of affected systems, removal of unauthorized access, application of patches, updates, or configuration changes, and restoration of services;
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the public-facing Incident Report:
3. Summarize the steps taken to address the root cause(s) and to strengthen security controls to prevent a similar vulnerability/incident in the future;
4. Detail any other steps being taken to mitigate the effects of the vulnerabilities/incident, including the status of each action, and the date each action will be completed; and
5. Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.
CA Remediation Measures
The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the public-facing Incident Report:
- Outline the remediation plan and actions taken to address the incident or identified vulnerabilities, weaknesses, or gaps in security controls;
- Specify the remediation steps you are taking to resolve the situation and ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, its current status of implementation, and the date that each step will be completed; and
- Provide details on any additional measures or enhancements implemented to improve the overall security posture of the CA.
Contact Information
Provide contact information for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.
