Incident Reponse Playbook

TODO

• Figure out what medium to use for communication. Signal? Matrix?

When to use this

Whenever a core team (listed below) realizes that the response to an incident requires more than one team to resolve. We expect this to be used mostly in security-related incidents (account compromise, severe security vulnerability, etc) but it is probably useful beyond that.

Following the process is expected to structure the response, figure out who is available and let volunteers plan their availability. The document also spells out some general expectations.

This document is informational for any beyond the incident responders and likely not directly applicable.

Prework

NOTE: ONLY if you are a member of the "Core response" teams listed below.

• Reach out to security@ to be added to the incident response group.

Step 1: Identify the teams involved

NOTE: All teams are listed with their private alias that is not accessible to the public.

Core response teams:

• Security team (security@)
• System Administrators (dsa@)
• FTP team (ftpmaster@)
• buildd maintainers (wb-team@buildd.d.o)

Also think about involving other teams (depends on the incident):

• Release team (team@release.d.o)
• Data Protection team (data-protection@)
• Account Managers (dam@)
• Keyring maintainers (keyring-maint@)
• Salsa (salsa-admin@)
• Cloud/Image teams (Contact TBD)

Think about involving these for awareness - likely without much detail:

• Leader (leader@)
• Publicity team (press@)

Step 2: Establish a communication channel

• The initial communication channel will likely be email, with a heads-up on the group.
• As you see the heads-up, please respond if and for how long you will be around. This is best effort: No-one is expected to be available - or should feel bad about not being available. No-one should be woken up if we can avoid it.

Step 3: Create a Salsa project for the response

• We have pre-created incident-response-team as a group to hold one project per response.
• Go to New project and create a new project, using a blank project. Coordinate with the others to only create one.
• The new project will be forcefully private and you will need to add people beyond the Core teams manually.

Step 4: Figure out workstreams

This will be very incident-dependent, but the following might help you:

• Shutting down access/processing
• Validating whether/how much of the infrastructure is compromised
• Validating whether/how much of the archive is compromised
• Finding and validating fixes
• Communication
  • Keeping track of state and work assignments (Salsa project)
  • Managing volunteer time
• External communication