Initial version: Foundation Incident Response Plan

[UlisesGascon]

This is a draft version of the Foundation’s Incident Response Plan.

Please feel free to comment per line or add general feedback directly in this PR.

The main goal is to kick off the discussion so we can refine and agree on the process in our next meeting on Monday and keep iterating this PR between meetings...

Nothing here is final at all... placeholders (🍿 @Discussion) are meant to capture open questions for the group.

[RafaelGSS]

I wonder if we could merge nodejs/security-wg#1511 here.

[shusak]

I believe we have to be specific on the details that are provided in order to have a "quality" report that avoids a lot of clarifications.

[UlisesGascon]

I assume that big part of it can be "shaped" in the web form (required fields, validation...)

[bensternthal]

I think this should be in order of most often occurring to least likely to occur

[UlisesGascon]

Agree with the idea, but not sure what is the best order... feel free to open a suggestion 👍

[bensternthal]

I think we should decide how communication and work here is co-ordinated. For example a common practice is that when an incident occurs, the incident commander creates a dedicated slack channel to facilitate communication.

[RafaelGSS]

I think we should have a more straightforward workflow in the event of a severe report.

For instance, if the report is from a Low ~ High vulnerability score, we follow the current runbook. However, we should have a direct line if the vulnerability is a potential Critical/Severe score.

[UlisesGascon]

For our next meeting... pending items:

• a straightforward workflow in the event of a severe report (ref) @RafaelGSS
• how communication and work here is co-ordinated (ref) @bensternthal
• Potential team members (nomination process, etc..)
• Sort categories (ref) @bensternthal
• report quality (ref) @shusak

[jonchurch]

In today's meeting folks were discussing the reality of having a coordinator assigned to an issue in volunteer and multi timezone based responses, with the fear that it reads as an On Call assignment.

I want to clarify that in my experience, the goal of having a coordinator (or Directly Responsible Individual) is to ensure that there is at most one perosn executing the duties of the role at a time. Any number of folks can help said coordinator, but responsibilities and communication should flow through the coordinator so efforts aren’t duplicated and others can stay focused.

That role can (and should) be handed off as needed, so long as handoff happens explicitly.

If 2 folks are responding to a new incident, the first step in formalizing the response would be to explicitly identify who among them will take on the coordinator role for the time being.

[ljharb]

In practice, though, timezone-of-residence doesn't determine availability. Everyone's sleep and work schedule is different, unrelated to timezone :-)

[UlisesGascon]

As agreed on last meeting I move this PR to "Ready for Review" with the aim of landing a first minimal version (this PR) while start working on additional topics in a separate PRs 👍

[bensternthal]

@UlisesGascon do you need anything additional on merging this one?

[UlisesGascon]

Probably some approvals to land this version while start working on a more advance one in a separate pr

[bensternthal]

This should be commented out if it is not up and running when the PR is merged. I am curious what this form will do, e.g. will it send an alert to slack? And I am happy to help set this up when we are ready.

[UlisesGascon]

Maybe a basic form (name, email, description, prefer contact method...) and send it to a channel in slack and/or specific team mail or individual emails?

Or... even enable advisories? and use that communication channel?

[UlisesGascon]

In the meantime this should be an option to unblock the PR f33192f :)

[bensternthal]

Added a few comments, I do think the form link should be resolved before this is published.