Discussion Draft: Foundation Incident Response Plan #289
Conversation
incident-response-plan.md
Outdated
|
|
||
| **Expectations** | ||
|
|
||
| - Provide detailed information about the suspected vulnerability. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I assume that big part of it can be "shaped" in the web form (required fields, validation...)
incident-response-plan.md
Outdated
|
|
||
| ## Scope | ||
|
|
||
| This plan covers incidents such as: |
There was a problem hiding this comment.
I think this should be in order of most often occurring to least likely to occur
There was a problem hiding this comment.
Agree with the idea, but not sure what is the best order... feel free to open a suggestion 👍
| - 🍿 @Discussion: early-stage idea, based on the Runbook: | ||
|
|
||
| ```mermaid | ||
| flowchart TD |
There was a problem hiding this comment.
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.
incident-response-plan.md
Outdated
| ## Runbook | ||
|
|
||
| - 🍿 @Discussion: What is the best approach? Some ideas: | ||
| 1. **REPORT Received** |
There was a problem hiding this comment.
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.
|
For our next meeting... pending items:
|
| - Assign SMEs as needed | ||
| - Keep reporter and affected projects updated | ||
| - Track all incidents for reporting and visibility | ||
|
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
In practice, though, timezone-of-residence doesn't determine availability. Everyone's sleep and work schedule is different, unrelated to timezone :-)
|
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 👍 |
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.