CA/Vulnerability Disclosure
Contents
- 1 Vulnerability Disclosure Requirements for Certification Authorities in the Mozilla Root Store
- 2 Markdown Template
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 in Bugzilla.
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 for non-compliances, 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”.
Don't check the Security box that says, "Many users could be harmed by this security problem: ...." That checkbox is for a different security review process.
All CA security disclosures will be treated with strict confidentiality. The information provided will remain private and secure throughout the investigation and resolution process. Once the incident is resolved, a new, separate, and public bug report should be created by the CA operator. Such public report shall contain only sanitized information that has been reviewed and approved by the CA operator to ensure that no confidential details are disclosed. But make sure that you report security incidents to other root stores as well. Note that Mozilla may share information with other root store representatives and add them to the cc: list with access to review and comment on such disclosures made in Bugzilla. (People cc:'ed in the bug have access to view the bug, so review the cc: list to ensure that no unintended people are in that list.)
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”.
Serious vulnerabilities include critical software and web application vulnerabilities, faulty APIs that could lead to data breaches, zero-day exploits, and malware infections.
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).
- Ransomware attacks, 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/Incident 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 nature of the compromise, the specific systems, infrastructure, or processes affected, the duration of the vulnerability/incident, and the identity of any threat actors.
- 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
See "Determining Significance" above. 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 subscribers, 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.
- Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.
- Detail any other mitigation steps or "action items" being taken to mitigate the effects of the vulnerabilities/incident, including the type of action (e.g. patching, access control, training, etc.), the status of each action, and the date each action will be completed.
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 summarize the actions to be taken to address the incident, root cause(s), or identified vulnerabilities, weaknesses, or gaps in security controls;
- Specify the remediation action items that you are taking to resolve the current situation, to address the root cause(s), and to ensure that a similar incident will not occur in the future. Include a timeline for completing each remediation step, the type of action (e.g. governance review, enhanced alerting, training, documentation, etc.), 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 (e.g. email address or group distribution list) for the responsible individuals within the CA’s organization who can address any further inquiries or provide additional information related to the vulnerability/incident.
Markdown Template
## Vulnerability/Incident Disclosure Form ### Concise Summary ### Vulnerability/Incident Details #### Timeline All times are UTC. YYYY-MM-DD: - HH:MM Example - #### Type and Detailed Description Nature of the compromise: Specific systems, infrastructure, or processes affected: Duration: Identity of threat actors: #### Root Cause(s) ### Severity/Impact Assessment #### Potential Impact on CA operations, systems, certificate trustworthiness #### Number and type(s) of certificates affected (if any) #### Potential impact on subscribers, relying parties, and others #### Escalation Potential ### Response and Mitigation #### Recommended Actions for Root Store(s) #### Immediate Actions Taken to Contain/Mitigate #### Collaboration with Forensics, CSIRTS, LEAs, etc. #### Mitigation Steps Being Taken | Action Item | Kind | Due Date | Status | | ----------- | ---- | -------- |-------- | | Example | Patching | 2024-01-19 | 50% complete | ### Remediation Plan #### Outline/Summary of Remediation Plan #### Remediation Action Items | Action Item | Kind | Due Date | Status | | ----------- | ---- | -------- | -------- | | Example | Governance Review | 2024-01-19 | 50% complete | #### Additional Measures ### Contact Information Email Address
