Incident Report format

[Gervase Markham]

It seems like the list of topics to cover on the Responding to a
Misissuance page:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
has become a de facto template for incident reports.

We've now had quite a few CAs use this outline to respond to issues. If
people (CAs or others) have feedback on how this template could be
improved, that would be a fine thing.

Gerv

[Ryan Sleevi]

Hi Gerv,

Based on the number of reports reviewed recently, I suspect we've got
opportunities for improvement, but I'm not quite sure yet what the concrete
suggestions on that should look like. A few thoughts below:

- The current report format biases itself towards "misissuance", when we
know there's a spectrum of BR compliance issues that can arise (for
example, the OCSP responders) that don't necessarily involve the
certificates and crt.sh IDs, but on other factors

- I would say that the majority of CAs had difficulty understanding what a
"timeline" was, often providing statements of steps they took, without any
context as to when - either date or time. They also tended to focus on when
the incident was reported to them, without taking into the full
consideration of when the situation causing the incident began.
- For example, if the BRs changed at Date X, and required the CA do
something by Date Y, and they didn't, then it would seem that at least Date
X and Y are relevant to the discussion (and potentially when the change was
first discussed in the CA/B Forum, which often far pre-dates Date X).
Further, if CAs' do audits or annual CPS reviews, understanding those in
the timeline are equally valuable, even when they predate the incident
itself.

- It's unclear the value of the confirmation of non-issuance or resolution.
If the intent is for the CA to make a binding pledge to the community with
respect to their corrective actions, perhaps it should be expanded (and the
consequences of misrepresenting that pledge captured)

- It's unclear what the reasonable expected update period should be when
CAs are taking corrective steps. Weekly updates?

If it helps, Microsoft requires the following of CAs that participate in
its program -
https://social.technet.microsoft.com/wiki/contents/articles/31633.microsoft-trusted-root-program-requirements.aspx#D_CA_Responsibilities_in_the_Event_of_an_Incident
- so one might expect that every CA participating in both programs has such
information available to them, when it's a BR violation.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Gervase Markham]

On 22/09/17 00:12, Ryan Sleevi wrote:
> Based on the number of reports reviewed recently, I suspect we've got
> opportunities for improvement, but I'm not quite sure yet what the concrete
> suggestions on that should look like. A few thoughts below:

Here's a set of changes which attempt to capture some of what you are
requesting. Further input, from you or others, is welcome.

https://wiki.mozilla.org/index.php?title=CA%2FResponding_To_A_Misissuance&diff=1181405&oldid=1179230

Gerv

[Jakob Bohm]

Suggested minor additional improvements to this excellent document:

1. Title should also reflect that this is now about various kinds of
incidents.

2. Opening paragraph should be split in two just before the definition
of "misissuance". A third paragraph should be added with a similar
spirit definition of "Other examples of incidents include ...".

3. In the definition of "misissuance" it may be prudent to add wording
to the effect that "revocation" at the request of the certificate
subject due to events entirely under the the subjects control are
typically not considered "misissuance", just routine revocation work.

4. Under "Follow-Up actions", second bullet, perhaps change "rigorous"
to "frequent/rigorous".

5. Under "Incident Report", item 1, add "internal self-audit" as another
example of discovery. (I think the recent DigiCert reissue incident
might be a good example of that happening).

6. Under "Incident Report", item 3, remove the word "TLS/SSL" to make
the bullet point equally applicable to e-mail certs, OCSP certs etc.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Gervase Markham]

On 29/09/17 20:08, Jakob Bohm wrote:
> 1. Title should also reflect that this is now about various kinds of
>   incidents.

The page is now called:
https://wiki.mozilla.org/CA/Responding_To_An_Incident

I've also made the other changes. Thank you for your feedback.

Gerv