Back to Thunderbird Android

Thunderbird for Android — Incident Response Plan

docs/security/incident-response-plan.md

6.9045.8 KB
Original Source

Thunderbird for Android — Incident Response Plan

This template that will help guide you through the process of handling security incidents and investigations.

There are 5 phases:

  1. Validation
  2. Mitigation
  3. Scoping
  4. Mitigation Notification
  5. Remediation

Each phase should be completed before moving to the next.


Guidance

  • Vulnerability Reporting Form (see SECURITY.md)
    • Note: Vulnerability Reports include CVSS scoring calculator
  • The CIA triad is used to evaluate security risks. Every vulnerability should be assessed against these principles:
    • Confidentiality
      • Keep data private and protected from unauthorized access
      • Example: Can the attacker read or exfiltrate email content, account settings, auth tokens, or attachment cache?
    • Integrity
      • Ensure data is accurate and not tampered with
      • Example: Can the attacker modify mailbox state, filters, server settings, or message contents rendered to the user?
    • Availability
      • Keep systems and data accessible when needed
      • Example: Can crafted content crash the app, deadlock sync, or brick startup (persistent DoS via mailbox state)?

Phase 1 - Validation

Updates

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.

  • Verified on Android 15 with Thunderbird 13.0
  • Requires custom-crafted email and user interaction
  • See sample email link for recreation
  • Potential Impact: Denial-of-service and possible memory corruption

Tasks

  • Understand the vulnerability
  • Update the vulnerability report with understanding
  • Determine severity based on CVSS scoring calculator
  • Decide if case will become an investigation. Either:
    • Dismiss report as not-actionable
    • Convert report to an investigation

Results

  • Is there a direct risk of CIA being broken? Yes|No
  • Which part of CIA could be broken? Confidentiality|Integrity|Availability
  • What user data is at risk?
  • What is required to exploit the vulnerability?
  • What is the severity? Low|Moderate|High|Critical
  • Vulnerability was introduced on: YYYY-MM-DD
  • Pull request where vulnerability was introduced? <url>
  • Versions of Thunderbird affected: <#.#>, ...

Phase 2 - Mitigation

Updates

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.

Tasks

  • Re-assess severity and update if necessary
  • Assess whether vulnerability also exists in other code paths
  • Update vulnerability report with mitigation

Results

  • The vulnerability required mitigation on: Nightly|Beta|Release
  • The vulnerability mitigated on: YYYY-MM-DD
  • The vulnerability mitigated on the following releases: <#.#>, ...
  • Link to mitigation work: <url>

Phase 3 - Scoping

Updates

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.

Tasks

  • Review available information sources (crash reports, GitHub issues, vulnerability reports, social networks, blogs, etc)
  • Determine if there was a confirmed breach in CIA
  • Confirm who was affected or might have been affected

Results

  • Scoping analysis link: <url>
  • Confidence in scoping completeness: low|medium|high
  • Was there a CIA breach? Yes|No
    • If yes, elaborate:
  • How many users were affected: <#>
  • All needed data available? Yes|No
    • If no, elaborate:

Phase 4 - Mitigation Notification

Updates

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:

  • Release notes
  • Thunderbird blog post (if high severity)

Tasks

  • Draft notification content
  • Internal FAQ + Support/Comms alert
  • Update GitHub and Play Store release notes
  • Optional blog post

Results

  • Notifications were sent/published on: YYYY-MM-DD:HH-MM-SSZ
  • Link to notification content? <url>
  • Is there a link to a blog/changelog that was published? <url>

Phase 5 - Remediation

Updates

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:

  • CVE
  • Thunderbird for Android Security Advisory
  • Release notes
  • Thunderbird blog post (if high severity)

Tasks

Results

  • CVE and advisory were published on: YYYY-MM-DD:HH-MM-SSZ
  • Link to notification content? <url>
  • Is there a link to a blog/changelog that was published? <url>