JUnit's Security Incident Response Checklist

JUnit's Security Incident Response Checklist

This checklist is inspired by an example from the GitHub PSIRT.

See also: https://github.com/resources/articles/security/what-is-incident-response

🏷️ 1. Phase: Lead validation

📢 Updates

<< Use this section to detail the report received, and include any repro results, mitigating factors and the impact of the issue >>

Ex:

I've read the report and validated this vulnerability does exists.

The exploit is difficult to achieve due to the following:

• It require precise timing and multiple steps to achieve.
• It requires a specific set of configurations, and advanced knowledge to identify repositories with these configurations.
• The repository owner must approve a PR from the bad actor before they can attempt this exploit.

The impact of the exploit:

• Enables a contributor with read access to gain write access.
• With write access, they can then alter workflows and source code.

🤓 Guidance

helpful things that can help you during this phase

<< Use this section to link to any reference documentation >>

• [Lead validation runbook]

✅ Tasks

things that should be completed before moving on

• Understand vulnerability/situation
• Update case summary with understanding
• Determine severity
• Decide if case will become an investigation. Either:
  • Dismiss lead as not-actionable and apply IR Lead - not actionable label
  • Convert lead to an investigation

🗒️ For the record...

what did you determine during this phase?

• 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 this situation?
• The vulnerability was introduced on: YYYY-MM-DD
• Is there a pull request where the vulnerability was introduced?

---

🏷️ 2. Phase: Mitigation

📢 Updates

<< use this section to call out any blockers, challenges, or successes. this section may contain a mitigation plan or strategy to execute >>

To prevent potential exploitation, we've disabled the feature where this vulnerability exists.

We identified the root cause, and are now working on a pull request to mitigate it at the root.

✅ Tasks

things that should be completed before moving on

• Re-assess severity and update if necessary
• Check product surfaces (Core GH, GHES, GHEC with Data Residency)
• Confirm mitigation across surfaces
• Use ir-labels to apply classification labels to this issue

🗒️ For the record...

what did you learn during this phase?

• The vulnerability was first mitigated on: YYYY-MM-DD
• The vulnerability affected: Core GH|GHES|GHEC w DR|other
• Is there a link to the mitigation work?

---

🏷️ 3. Phase: Scoping

📢 Updates

We have run an analysis and identified 751 impacted users.

✅ Tasks

things that should be completed before moving on

Scoping is the process of interrogating our data to determine if a vulnerability was used and/or exploited, and what the impact was. Some useful prompts are:

What is the goal of the scoping work? Writing down specific goals can help reframe the work that needs done. How can you identify expected vs exploitative use? Are you able to find known use of the vulnerability in the data? Perhaps from the security researcher or from internal validation of the vulnerability.

• Review available information sources
• Determine if there was a confirmed breach in CIA. If yes, delcare this case an incident by:
  • Updating the title to [Incident]
  • Applying the Incident label
• Confirm who was affected or might have been affected

📓 Notes

add your scoping notes here

🗒️ For the record...

what did you learn during this phase?

• What is the link to your scoping notebook?
• What is your confidence in the completeness of the scoping? low|medium|high
• Was there a CIA breach? Yes|No
• How many individual user accounts were affected?
• How many organization or enterprise accounts were affected?
• Were you able to find the data you needed? If not, how come?

---

🏷️ 4. Phase: Notification

📢 Updates

We have opted to send a direct email notification to all 751 users to inform them of our findings, and provide instruction on how to audit their information.

✅ Tasks

things that should be completed before moving on

• Are we going to notify for this case? Yes|No

If No, feel free to delete the checklist below 👇

When the case moves to the notification phase, please complete this checklist from our preparing to send a notification runbook to ensure all required actions are taken:

• When the decision is made to notify
  • Double check product involvement
  • Draft notification content
  • Prepare data required to send notifications
• Leadership Escalations
  • Summary of issue, notification draft, and # of notifications has been shared to escalate to leadership
• When the draft notification content is complete
  • Get approvals:
    • Legal
    • Corporate communications team
    • Security Leadership
• More then 24 hours before notification send time (ideally)
  • Create FAQ for internal consumption
  • Alert Support
  • Provide data/logs for support if possible/applicable
• When the shared notification time occurs
  • Publish other materials if applicable
    • GHES release notes
    • Blog post/changelog
  • Send notifications
• When the notifications have been sent
  • Update stakeholder channels
  • Update Support that notifications are sent
  • Commit and push notification artifacts to the case repository
  • Keep an eye on support channels and assist where possible

🗒️ For the record...

what happened during this phase?

• When were notifications sent/published? YYYY-MM-DD:HH-MM-SSZ
• How many notifications were sent?
• What is the link to the notification content?
• Is there a link to a blog/changelog that was published?