Security Incident Reporting Work Party Update
Dear RSSAC Caucus Members, Ken, Robert S and I met yesterday to work on the document. https://docs.google.com/document/d/1NvSw7PoLGYhXPuMEjiBgqjCtp_khTGGEh0DaHkNJ... Below are some changes we made to the document that we can discuss on our next work party call. -In Section 4.5 we reduced the number of categories from 5 to 3 by removing Catastrophic and Informational. The remaining incident categories are Low, Medium and Major. We also renamed the section "Incident Severity Guidelines". -Deleted the table in Section 4.5. It was originally Suggested for deletion during the meeting of March 25. -Created a new Section Y immediately before Section 6. The intention of Section Y is to eventually replace Section 6. It incorporates elements from Robert's Section X, that we discusssed on the last work party call, and Section 6. It's more high-level and less proscriptive than the current Section 6. -Deleted Section X and incorporated it's content into Section Y. -We started adding links back to the Statement of Work in brackets []. We want to be able to track where we are addressing the different elements in the SoW in the document. This bracketed text will be deleted prior to publishing the document. Please add any Suggestions into the document prior to our next work party call on April 22nd 15:00 UTC. Thanks, Andrew
On Tue 2024-04-16 10:06:59+0000 Andrew wrote:
-In Section 4.5 we reduced the number of categories from 5 to 3 by removing Catastrophic and Informational. The remaining incident categories are Low, Medium and Major. We also renamed the section "Incident Severity Guidelines".
We also tried to make them less proscriptive (ie removed references to the number of RSOs involved). A random thought popped into my head while typing this response. I just added a comment in section 5 (What to report): Thoughts on having two severity impact fields: RSS impact, and RSO impact?
Please add any Suggestions into the document prior to our next work party call on April 22nd 15:00 UTC.
It's also ok to comment or start discussions on the list. I feel like the lists are less used since we stopped having per-work-party lists. If you generally aren't able to make the zoom calls (or don't want to), start a thread on the list, prefixing the subject with 'SIR wp:' or something like that. Regards, Robert -- USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division
On Tue, Apr 16, 2024 at 8:03 AM Robert Story <rstory@ant.isi.edu> wrote:
[..] A random thought popped into my head while typing this response. I just added a comment in section 5 (What to report): Thoughts on having two severity impact fields: RSS impact, and RSO impact?
My opinion is to keep reporting focused only on the RSS. -Ken
Here is a security incident report that supports our approach(covering indirect incidents), i.e., including security incidents related to critical infrastructure components upon which the RSS relies. https://status.ripe.net/incidents/l3cz0rry823k Dessalegn On Tue, Apr 16, 2024 at 4:06 PM Ken Renard <kdrenard2@gmail.com> wrote:
On Tue, Apr 16, 2024 at 8:03 AM Robert Story <rstory@ant.isi.edu> wrote:
[..] A random thought popped into my head while typing this response. I just added a comment in section 5 (What to report): Thoughts on having two severity impact fields: RSS impact, and RSO impact?
My opinion is to keep reporting focused only on the RSS.
-Ken _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Dessalegn, I think this would fall under an informational report, because: - it was caused by a bad configuration update, not a malicious actor - it affected less than 25% of a single RSO, so no material effect on the RSS While I think/hope that we will include a recommendation that RSSAC or the RSS GS consider creating guidance for information reporting, it's otherwise out of scope for the current document. Regards, Robert USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division On Mon 2024-04-22 10:37:01+0300 Dessalegn wrote:
Here is a security incident report that supports our approach(covering indirect incidents), i.e., including security incidents related to critical infrastructure components upon which the RSS relies.
https://status.ripe.net/incidents/l3cz0rry823k
Dessalegn
participants (4)
-
Andrew McConachie -
Dessalegn Yehuala -
Ken Renard -
Robert Story