You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: idpy-incidentresponse.md
+4-6Lines changed: 4 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Security Incident Response Plan for Identity Python-governed Projects
2
2
3
-
## Version 0.3 2018-07-25
3
+
## Version 0.4 2020-02-06
4
4
5
5
The following details the steps and actions that we should consider when
6
6
responding to security issues related to projects governed by the Identity
@@ -11,11 +11,9 @@ contributors.
11
11
12
12
| Stage | Activities |
13
13
| ----- | ---------- |
14
-
| Discovery | Reporter: <ul> <li>Anyone can submit a potential security vulnerability to <incident-response@idpy.org> </li></ul>Security Monitor:<ul><li>Semi-permanent role identified by the Identity Python Board of Directors. This person sits on the <incident-response@idpy.org> list.</li><li>Creates issue in the appropriate IdentityPython GitHub project space, anonymizing the report if requested to do so by the reporter.</li><li>Sends an email regarding the potential issue to the Board.</li><li>Acknowledges reporter.</li></ul> |
15
-
| Assignment | Security Monitor:<ul><li>Ensures an Incident Manager has been assigned.</li></ul>Incident Manager:<ul><li>Semi-permanent, rotating, or volunteer role identified by the Board and likely a member of the committee.</li><li>Identifies a Technical Resource and assigns the issue to them.</li><li>Subscribes to updates on the issue.</li><li>Contacts the reporter and introduces them to the technical resource.</li></ul>Technical Resource:<ul><li>A just-in-time role identified by the Incident Manager from a pool of best-effort committers familiar with the process for handling security incidents. Before the issue can be assigned, the Incident Manager needs to work with the potential assignee to ensure they are in a position to assess on the issue (i.e., have the time, have the knowledge).</li></ul>|
16
-
| Assessment | Technical Resource:<ul><li>Validates – confirms a vulnerability exists</li><li>Classifies - Severity/Impact of the vulnerability is determined using Common Vulnerability Scoring System ([CVSS]). Specific potential impact to application is noted (e.g., Exploit allows Admin level access to application).</li><li>Identifies affected products/versions - Identifies all versions affected by the vulnerability and makes a note in the issue.</li><li>Briefs the reporter on the assessment as appropriate.</li></ul>|
17
-
| Remediation | Technical Resource: <ul><li>Works with other technical resources in the community on the remediation.</li><li>Identifies remediation options and determine best remediation strategy as a result of the analysis.</li><li>Implements a fix for issue in a the appropriate project repo.</li><li>Validates that the issue is resolved. Ideally this involves a second organization.</li><li>Creates a test to verify the issue does not come up again in future versions.</li></ul>Incident Manager:<ul><li>Monitors progress on issue resolution.</li><li>Provides updates to steering committee as appropriate.</li></ul>|
18
-
| Community Disclosure & Patch Release | Technical Resource (or separate release engineer):<ul><li>Creates patch release or remediation instructions.</li><li>Publishes patch release in consultation with the Incident Manager.</li></ul>Incident Manager:<ul><li>Sends disclosure notice to code repository owners.</li><li>Obtains a Common Vulnerabilities and Exposures Identifier ([CVE-ID])</li></ul> |
14
+
| Discovery and Assignment | Reporter: <ul> <li>Anyone can submit a potential security vulnerability to <incident-response@idpy.org> </li></ul>Project Architect:<ul><li>Creates issue in the appropriate IdentityPython GitHub project space, anonymizing the report if requested to do so by the reporter.</li><li>Sends an email regarding the potential issue to the Board.</li><li>Acknowledges reporter.</li></ul> |
15
+
| Assessment and Remediation | Project Architect:<ul><li>Validates – confirms a vulnerability exists</li><li>Classifies - Severity/Impact of the vulnerability is determined using Common Vulnerability Scoring System ([CVSS]). Specific potential impact to application is noted (e.g., Exploit allows Admin level access to application).</li><li>Identifies affected products/versions - Identifies all versions affected by the vulnerability and makes a note in the issue.</li><li>Briefs the reporter on the assessment as appropriate.</li><li>Works with other technical resources in the community on the remediation.</li><li>Identifies remediation options and determine best remediation strategy as a result of the analysis.</li><li>Implements a fix for issue in a the appropriate project repo.</li><li>Validates that the issue is resolved. Ideally this involves a second organization.</li><li>Creates a test to verify the issue does not come up again in future versions.</li></ul>|
16
+
| Community Disclosure and Patch Release | Project Architect:<ul><li>Creates patch release or remediation instructions.</li><li>Publishes patch release in consultation with the Incident Manager.</li><li>Sends disclosure notice to code repository owners.</li><li>Obtains a Common Vulnerabilities and Exposures Identifier ([CVE-ID])</li></ul> |
19
17
| Post-Mortem Retrospective | <ul><li>The Board discusses the Security Incident Response Plan as it played out for this incident, inspecting and adapting to handle the next one better.</li><li>The <discuss@idpy.org> list discusses the technical substance of the vulnerability and its fix, identifying opportunities to refactor the fix in subsequent releases now that it has more eyes on it and opportunities to improve the product and development practices to prevent or mitigate similar issues in the future.</li></ul> |
0 commit comments