MRSP 2.9: Issues #252 and #266 - Incident Reporting
Ben Wilson
All,
We are proposing to revise Mozilla Root Store Policy (MRSP) Section 2.4 (Incidents) to address GitHub Issue # 252 and Issue # 266.
Issue #252 - Requirements for Reporting CA Security Incidents
As noted in Issue #252, more guidance is needed for reporting security incidents to Mozilla. I am drafting a wiki page that will outline what is a reportable security incident and what a security incident report should contain. Thus, MRSP section 2.4 will be amended to read something to the effect, " 'Reportable Security Incident' means any security event, breach, or compromise that has the potential to significantly impact the confidentiality, integrity, or availability of CA infrastructure, CA systems, or the trustworthiness of issued certificates. A Reportable Security Incident MUST be reported with a security incident report in Bugzilla [link to Bugzilla security incident report template] as soon as possible and no later than __ hours, as described in [wiki page]. Additionally, other important security incidents and compromises of a CA operator's internal systems SHOULD be reported."
Issue #266 – Update reference to https://www.ccadb.org/cas/incident-report
Also, Issue #266 will be addressed by pointing to the CCADB's incident report requirements. The following language in MRSP section 2.4 will be amended to read, "CA Operators must report incidents to Mozilla in the form of an Incident Report that follows guidance provided on the CCADB website - https://www.ccadb.org/cas/incident-report."
I look forward to your comments and suggestions regarding security incident reporting.
Thanks,
Ben
Matt Palmer
> effect, " 'Reportable Security Incident' means any security event, breach,
> or compromise that has the potential to significantly impact the
> confidentiality, integrity, or availability of CA infrastructure, CA
to interpretation, and history has shown that CAs aren't shy about
interpreting things in a manner most favourable to their interests. I don't
see any real problem with requiring CAs to report *everything* with the
potential to impact CIA of CA-related things, because even minor hiccups can
become major, and they can also be a learning experience for everyone --
which is the same reason why most safety-critical industries require the
reporting of near-misses, not just actual incidents.
- Matt
Roman Fischer
The way towards something like full disclosure is a difficult one to walk. I was working in the airline industry for a couple of years and experienced firsthand what it means to establish and nurture a "no blame" culture that truly motivates people to talk about mistakes, drifts towards unsafe behaviour and such. It's a long process and all participants need to want to support it.
I think that the current process of disclosing incidents publicly on Bugzilla does not help build a "full disclosure - no blame" culture. So CA's (and all the other participants in the ecosystem) will continue to try and limit the possible negative impact of what they have to disclose.
From my point of view, it makes no big difference if the word "significant" is there or not. As long as the culture is "blame and shame", all participants will think more than twice before posting a Bugzilla.
Kind regards
Roman
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZK5CExtS3j0cKC5t%40hezmatt.org.
Ben Wilson
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZRAP278MB05627473060C050F4B0EB20CFA36A%40ZRAP278MB0562.CHEP278.PROD.OUTLOOK.COM.