Incident External Communication

[imix]

Hi all,

As discussed on the slack channel, I move this here:

The current incident management practice focuses on mostly on internal response activities (classification, RCA, forensics, team readiness). External communication is not well covered. There is a mention in O-IM-2-B but no criteria.

https://github.com/owaspsamm/core/blob/develop/model/activities/O-IM-2-B.yml:

rules for involvement of different stakeholders including senior management, Public Relations, Legal, privacy, Human Resources, external (law enforcement) authorities, and customers; specify mandatory timeframe to do so, if needed

This is becoming a compliance requirement in several jurisdictions (e.g. CRA Article 14, NIS2), but it also reflects a basic maturity expectation independent of regulation. A proper process is essential to give the clients an indication on how to handle an incident (in particular if the communication channel could be affected by the incident as well).

A possible addition for the quality crieteria could be:
L1: You have a defined owner responsible for external notifications
L2: You follow a documented process for customer notification and regulatory reporting
L3: You track notification success and customer reaction to improve your response process

Thoughts?

regards
Stefan

[maximbaele]

Hi Stefan, thank you for raising this!

Offering my personal experiences and opinion below, which (caveat!) doesn't necessarily reflect the "core team" opinion at the moment.

The way I validate notification obligations during assessments is as part of the G-PC-A/B evaluation, where I first have discussions with the team on what external regulatory or market-driven obligations they have, and how these obligations are translated into policies, processes and code. This is where I tend to have the first discussions on vulnerability handling, CVD and external notification obligations.
I then pick in on this when assessing O-IM-A/B, where I first want to know what (technical) prerequisites are foreseen in the product or application, such as what logging data is available, how accessible is it and to whom, what documentation or processes are in place that allow personnel or customers to evaluate logs, ...
Subsequently I evaluate how the organization level makes use of the prerequisites, how formal their incident response is and how it integrates with the external obligations discussed in G-PC-A/B.

I vastly prefer having every stakeholder in the room during assessments, but unfortunately I often have to split up interviews along the business function lines, which is one of the drivers of splitting the discussion on external notification over these two practices.
Another reason is because 99% of my usage of the SAMM model is for evaluating products, either hardware of software for which the end user is responsible for (part of) the Operations activities. So I focus a lot on evaluating the practical aspects of incident detection and incident response in the O-IM-A stream, with questions such as "what types of logs are you making available that can be used for incident detection?" "Do you have documentation that supports the integration of logs into SIEM systems?" "How do you protect audit logs?" and so forth. In O-IM-B I tend to focus on evaluating the shared responsibility model between the manufacturer and customer (or even end-user). This is where I pick up on CVD on one hand, and external notification obligations on the other hand.

So to your suggestion, I'd agree that we want to include at minimum some community guidance in the current version of the model that covers external communication. This will be the quickest way to codify it as part of the model. @imix Would you like to take a stab at that? Happy to help. I'm also open to collaborating on documentation that covers this, which can be published on the website.

If this we'd adopt quality criteria around this as part of the core model, it would change ("break") scoring, so can only be taken into a new version of the model. We've started discussions on the next iteration(s) of the model last year and are now in the early stages of collecting input. Your suggestion has to be part of this input, and we'll move the ticket accordingly, but we're currently moving very slowly with the discussions, so I don't expect "SAMMv3" to be ready in the short time.

In short, having this input codified as part of guidance/documentation would be a first step if you ask me, as a next step we can take this input in as part of the core model

[imix]

Hi @maximbaele

I can certainly help create a community guidance. Would this be published here: https://owaspsamm.org/docs/guides ? Maybe we can have a chat on how to approach this when time permits.

No worries on the inclusion in the criteria. We all want to have a stable scoring (i assume), so this is an obvious consequence of that.

Stefan