CA/Vulnerability Disclosure: Difference between revisions

← Older edit

CA/Vulnerability Disclosure (view source)

Revision as of 20:59, 11 June 2024

2,524 bytes added , 11 June 2024

→‎How to Disclose a Reportable Vulnerability: Added paragraph re: confidentiality

Bwilson

Confirmed users

377

edits

@@ Line 11: / Line 11: @@
 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.
+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 [https://www.ccadb.org/cas/incident-report public-facing Incident Report], as required by section 2.4 of Mozilla’s Root Store Policy.
+The requirement to disclose a Reportable Vulnerability is separate and in addition to the requirement to provide a [https://www.ccadb.org/cas/incident-report 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:
@@ Line 32: / Line 32: @@
 [[File:CA-Security-Bug.png|300px]]
+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 ===
@@ Line 37: / Line 41: @@
 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 “'''[[CA/Vulnerability_Disclosure#Determining_Significance|Determining Significance]]'''”.
-'''Security Incidents include the following:'''
+'''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).
-* Malware infections, ransomware, or other data integrity issues that irrecoverably damage or compromise sensitive CA data.
+* 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.
@@ Line 84: / Line 90: @@
 Additional guidance can also be found in various publications from [https://www.enisa.europa.eu/publications/article19-incident-reporting-framework ENISA], [https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf NIST], [https://www.cyber.gc.ca/en/guidance/introduction-cyber-threat-environment the Canadian Centre for Cybersecurity], and [https://academic.oup.com/cybersecurity/article/9/1/tyad009/7160387 academia].
-=== Reportable Vulnerability Disclosure Contents ===
+=== 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.
@@ Line 93: / Line 99: @@
 ==== 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.
+# 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 [https://www.ccadb.org/cas/incident-report public-facing Incident Report].
-==== Severity / Impact Assessment ====
+==== 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 certificate holders, relying parties, and other stakeholders; and
+# 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;
+# 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 [https://www.ccadb.org/cas/incident-report public-facing Incident Report]:
-. Summarize the steps taken to address the root cause(s) and to strengthen security controls to prevent a similar vulnerability/incident in the future;
+# 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 ==
+<pre>
+## 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 |
-. 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
-. Highlight any collaboration or assistance received from external parties, such as incident response teams, forensics, or law enforcement.
+### Remediation Plan
-==== CA Remediation Measures ====
+#### Outline/Summary of Remediation Plan
-The following information does not need to be duplicated in the Reportable Vulnerability bug if it can be fully provided in the [https://www.ccadb.org/cas/incident-report public-facing Incident Report]:
-# Outline the remediation plan and actions taken to address the incident or identified vulnerabilities, weaknesses, or gaps in security controls;
+#### Remediation Action Items
-# 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.
+| Action Item | Kind | Due Date | Status |
+| ----------- | ---- | -------- | -------- |
+| Example | Governance Review | 2024-01-19 | 50% complete |
+#### Additional Measures
+### Contact Information
-==== Contact Information ====
+Email Address
-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.
+</pre>