Confirmed users
377
edits
CA/Responding To An Incident: Difference between revisions
Jump to navigation
Jump to search
→Incident Report: Miscellaneous edits and mention of CCADB Public list
m (Changed Bugzilla Product from NSS to CA Program per Bugzilla Bug #1799573) |
(→Incident Report: Miscellaneous edits and mention of CCADB Public list) |
||
| Line 72: | Line 72: | ||
The incident report may well repeat things which have been said previously in discussions or bug comments. This is entirely expected. The report should be a summary of previous findings. The existence of data in discussions or bug comments does not excuse a CA from the task of compiling a proper incident report. | The incident report may well repeat things which have been said previously in discussions or bug comments. This is entirely expected. The report should be a summary of previous findings. The existence of data in discussions or bug comments does not excuse a CA from the task of compiling a proper incident report. | ||
Your CA | Your CA must submit an incident report by [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&version=other creating a bug in Bugzilla under the CA Program :: CA Certificate Compliance component]. When the incident is reported only on the CCADB public list or on the [https://groups.google.com/a/mozilla.org/g/dev-security-policy MDSP mailing list], then a bug will be created to track the incident and its resolution in Bugzilla. CAs are encouraged to announce important incidents on public@ccadb.org when they involve the Baseline Requirements, other root programs, or the CCADB; or on the Mozilla dev-security-policy list, when they only involve violations of the Mozilla Root Store Policy. | ||
The incident report should cover at least the following topics: | The incident report should cover at least the following topics: | ||
| Line 82: | Line 82: | ||
# In a case involving TLS server certificates, the complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. It is also recommended that you use this form in your list "<nowiki>https://crt.sh/?sha256=[sha256-hash]</nowiki>", unless circumstances dictate otherwise. When the incident being reported involves an SMIME certificate, if disclosure of personally identifiable information in the certificate may be contrary to applicable law, please provide at least the certificate serial number and SHA256 hash of the certificate. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any. | # In a case involving TLS server certificates, the complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. It is also recommended that you use this form in your list "<nowiki>https://crt.sh/?sha256=[sha256-hash]</nowiki>", unless circumstances dictate otherwise. When the incident being reported involves an SMIME certificate, if disclosure of personally identifiable information in the certificate may be contrary to applicable law, please provide at least the certificate serial number and SHA256 hash of the certificate. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any. | ||
# Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. | # Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. | ||
# List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied | # List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied by a binding timeline of when your CA expects to accomplish each of these remediation steps. | ||
The purpose of these incident reports is to provide transparency about the steps the CA is taking to address the immediate issue and prevent future issues, both the issue that originally | The purpose of these incident reports is to provide transparency about the steps the CA is taking to address the immediate issue and prevent future issues, both the issue that originally led to the report, and other potential issues that might share a similar root cause. Additionally, they exist to help the CA community as a whole learn from potential incidents, and adopt and improve practices and controls, to better protect all CAs. Mozilla expects that the incident reports provide sufficient detail about the root cause, and the remediation, that would allow other CAs or members of the public to implement an equivalent solution. | ||
For example, it’s not sufficient to say that “human error” | For example, it’s not sufficient to say that “human error” or “lack of training” was a root cause for the incident, nor that “training has been improved” as a solution. While a lack of training may have contributed to the issue, it’s also possible that error-prone tools or practices were required, and making those tools less reliant on training is the correct solution. When training or a process is improved, the CA is expected to provide specific details about the original and corrected material, and specifically detail the changes that were made, and how they tie to the issue. Training alone should not be seen as a sufficient mitigation, and focus should be made on removing error-prone manual steps from the system entirely. | ||
= Keeping Us Informed = | = Keeping Us Informed = | ||