Confirmed users, Administrators
5,526
edits
CA/Responding To An Incident: Difference between revisions
Updated due to MDSP migration
m (Updated due to MDSP migration) |
(Updated due to MDSP migration) |
||
| Line 71: | Line 71: | ||
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 may submit an incident report by [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other creating a bug in Bugzilla under the NSS:CA Certificate Compliance component], or by posting the report to the mozilla.dev | Your CA may submit an incident report by [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other creating a bug in Bugzilla under the NSS:CA Certificate Compliance component], or by posting the report to the [https://groups.google.com/a/mozilla.org/g/dev-security-policy MDSP mailing list]. If an incident report is sent to the list without a corresponding bug, a new one will be created to track the incident. | ||
The incident report should cover at least the following topics: | The incident report should cover at least the following topics: | ||
# How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev | # How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in the [https://groups.google.com/a/mozilla.org/g/dev-security-policy MDSP mailing list], a Bugzilla bug, or internal self-audit), and the time and date. | ||
# A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. | # A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. | ||
# Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation. | # Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation. | ||