docs/security/incident-response-plan.md
This template that will help guide you through the process of handling security incidents and investigations.
There are 5 phases:
Each phase should be completed before moving to the next.
In this section, summarize the report, steps to recreate, mitigating factors, and potential impact.
Example:
We received a report of a crash triggered by malformed S/MIME messages.
Yes|NoConfidentiality|Integrity|AvailabilityLow|Moderate|High|CriticalYYYY-MM-DD<url><#.#>, ...In this section, note any blockers, challenges, or progress on mitigation. This phase is only necessary in circumstances where the remediation is not possible in a reasonable amount of time.
Example: We disabled the inline S/MIME rendering feature flag as a temporary mitigation. Root cause identified in MIME parsing logic.
Nightly|Beta|ReleaseYYYY-MM-DD<#.#>, ...<url>In this section describe the scoping results. Interrogate data to determine if the vulnerability was exploited, and what the impact was.
Example: Crash telemetry indicates 1,200 users impacted on version 13. No evidence of public exploit in use.
<url>low|medium|highYes|No
<#>Yes|No
In this section describe the mitigation notification plans. This phase is only necessary in circumstances where the remediation is not possible in a reasonable amount of time.
Example: We will notify users with our findings on this vulnerability, provide instruction on what version contains the mitigation, and how to audit their device for exploitation.
We will notify via:
YYYY-MM-DD:HH-MM-SSZ<url><url>In this section describe the remediation plans.
Example: We are providing a patch to the MIME parsing logic to fix the vulnerability. We will again notify users with our findings on this vulnerability, provide instruction on what version contains the mitigation, and how to audit their device for exploitation.
We will notify via:
YYYY-MM-DD:HH-MM-SSZ<url><url>