Improving: Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

[simoneonofri]

Hi all,

I want to incorporate some early feedback from our reviews with @innotommy and @KimCerra on some standards.

The first point is related to improving the question “Does this specification have both ‘Security Considerations’ and ‘Privacy Considerations’ sections?” to “Does this specification have both well-structured ‘Security Considerations’ and ‘Privacy Considerations’ sections?”
And then specify in the accompanying text how the structure should be, at least for the Security part, should provide an boilerplate structure (inspired by RFC 3552) such as:

• Introduction: a brief description of the security impact of the feature and assets to be protected.
• Security Assumptions: paraphrasing what is described in the Common Criteria, section 7.1.4, assumptions are those elements that are considered true about the operating environment of the feature (e.g., C2PA's Assumptions).
• Attacks/Threats: list of attacks or threats with title and a brief description (e.g., Vibration API 2024-06-28 > 2024-09-20 security-request#71 (comment)). For each attack/threat:
  • Mitigations/Countermeasures:
    • If it is in-scope: title and description of the countermeasures, referring to the specific section in which it is described. If the group decided not to apply any mitigation/countermeasure to the Attack/Threat, write a rationale for accepting that risk (business justification).
    • If it is out-of-scope: describe why.
  • Residual Risk: after the application (e.g., Vibration API 2024-06-28 > 2024-09-20 security-request#71 (comment)).

This assumes that this section is derived from (if not even) the Threat Model used.

Indeed, we noted that threat modeling is often used, and it would be useful to systematize the output.

Further guidance on how to make Threat Models (of Security, but also welcome those related to other threat categories) will be deliverables from the Security Interest Group since some standards are Web/Browser APIs, others File Format, and rarely protocols.

This addresses threats in the early stages and makes our reviews more efficient and effective.

If it makes sense to you, I can prepare a PR.

[jyasskin]

Before making this change to the questionnaire (and thereby asking all spec authors to understand what it means), I'd like to be able to point to 2-3 specs that you think follow the new rules. Can the Security IG send PRs to a few specs to bring them up to this standard, and then include links in the PR you post here?

[simoneonofri]

thx @jyasskin, we're working actively on this for Vibraton API, VCDM, and FedCM