Thanks for the helpful summary Andrew! Wes Hardaker USC/ISI On Tue, Jul 16, 2024 at 02:08 Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus Members,
Myself, Ken, and Robert S had a meeting yesterday to discuss the Security Incident Reporting Work Party working document.
We decided to cancel the meeting on Monday July 22 because it conflicts with IETF 120. Our next work party meeting will be on August 5.
We accepted some Suggestions to the working document that the work party had discussed previously and made a few more. There has been a lot of new comments and good discussion in the document so if you haven't looked at it in a while please do so if you have the time.
The big edit was to accept the new text in Section 4 that the work party has been discussing. The old, now deleted text is included at the bottom of this mail so we have a record of it.
https://docs.google.com/document/d/1NvSw7PoLGYhXPuMEjiBgqjCtp_khTGGEh0DaHkNJ...
Thanks, Andrew
Old text from Section 4: Security incidents that adversely and materially affect the availability, confidentiality, or integrity of the RSS should be reported by the affected RSO(s). This does not preclude the reporting of incidents that do not materially affect the RSS. The decision to report, or not, an incident is a context-specific decision made by the reporter based on their experience, knowledge of the RSS, understanding of the incident’s material implications for the RSS, and to be more transparent.
Not all security incidents affecting the availability, confidentiality, or integrity, or availability of RSS instances come under the scope of this report. RSOs should keep in mind that reporting too many false-positive security incidents could generate “noise” and obscure real incidents. On the other hand, reporting too few incidents risks missing critical incidents. Any RSO may publish information about events that do not meet the definition or threshold of being security incidents. These reports will be published at the discretion of the RSO for additional transparency. Reports may be periodic or ad-hoc.
_______________________________________________ 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.