Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
CA/Responding To An Incident: Difference between revisions
CA/Responding To An Incident (view source)
Revision as of 16:11, 28 September 2017
, 28 September 2017Updates based on sleevi's suggestions
(Remove draft status, and minor edits) |
(Updates based on sleevi's suggestions) |
||
| Line 1: | Line 1: | ||
The page gives guidance to CAs as to how Mozilla expects them to react to reported misissuances, and what the best practices are. For the purposes of this page, a "misissuance" is defined as any certificate issued in contravention of any applicable standard, process or document - so it could be RFC non-compliant, BR non-compliant, issued contrary to the CA's CP/CPS, or have some other flaw or problem. Researchers who | The page gives guidance to CAs as to how Mozilla expects them to react to reported incidents such as misissuances, and what the best practices are. For the purposes of this page, a "misissuance" is defined as any certificate issued in contravention of any applicable standard, process or document - so it could be RFC non-compliant, BR non-compliant, issued contrary to the CA's CP/CPS, or have some other flaw or problem. Researchers who report CA incidents such as misissuances are welcome to include a link to this page in their report to the CA, reminding the CA that Mozilla has the following expectations. This document is framed in terms of misissuance of certificates; it will need to be adapted as necessary for incidents of a different nature, respecting the spirit of the information requests contained therein. | ||
While some forms of misissuance may be seen as less serious than others, opinions vary on which these are. Mozilla sees all misissuances as good opportunities for the CA to test that their incident response processes are working well, and so we expect a similar level of timeliness of response and quality of reporting for all incidents, whatever their adjudged severity. | While some forms of misissuance may be seen as less serious than others, opinions vary on which these are. Mozilla sees all misissuances as good opportunities for the CA to test that their incident response processes are working well, and so we expect a similar level of timeliness of response and quality of reporting for all incidents, whatever their adjudged severity. | ||
| Line 7: | Line 7: | ||
= Immediate Actions = | = Immediate Actions = | ||
In | In misussuance cases, a CA should almost always immediately cease issuance from the affected part of your PKI until you have diagnosed the source of the problem, or explain why this has not been done. | ||
Once the problem is diagnosed, you may restart issuance even if a full fix is not rolled out, if you are able to put in place temporary or manual procedures to prevent the problem re-occurring. You should not restart issuance until you are confident that the problem will not re-occur. | Once the problem is diagnosed, you may restart issuance even if a full fix is not rolled out, if you are able to put in place temporary or manual procedures to prevent the problem re-occurring. You should not restart issuance until you are confident that the problem will not re-occur. | ||
| Line 53: | Line 53: | ||
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, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date. | # How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the time and date. | ||
# A timeline of the actions your CA took in response. | # 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, issuing TLS/SSL certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. | ||
# A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. | # A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. | ||
# 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. | # 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. | ||
| Line 63: | Line 63: | ||
= Keeping Us Informed = | = Keeping Us Informed = | ||
Once the report is posted, you should provide | Once the report is posted, you should provide updates at least every week giving your progress, and confirm when the remediation steps have been completed - unless Mozilla representatives agree a different update schedule with you. Such updates should be posted to the m.d.s.p. thread, if there is one, and the Bugzilla bug, if there is one. The bug will be closed when remediation is completed. | ||
= Examples of Good Practice = | = Examples of Good Practice = | ||