Decide security (issue) report handling team and procedure

[baentsch]

Currently only two OQS sub projects have publicly documented SECURITY.md handling procedures defined. The set of people receiving "privately" reported security vulnerabilities in those is pretty large (>10) as per open-quantum-safe/oqs-provider#451 (comment).

This issue is to codify and reduce this number to people explicitly agreeing and able to handle security incidents (e.g., a Vulnerability Management Team) and to decide whether other OQS sub projects should be subject to this procedure as well.

[baentsch]

This to also document the verbal agreement by @hartm and @dstebila in facilitating a "dry-run" security incident handling exercise with the team designated by way of resolving this issue. One goal of this is to get input regarding responsibilities of a maintainers and contributors in this regard.

[TheFoxAtWork]

In case this group finds these resources useful for that discussion, the incident response file may be particularly helpful.
https://github.com/cncf/tag-security/tree/main/community/resources/project-resources#security-resources-for-projects

A special thank you to Google's OSS vulnerability guide folks for making the Security TAG aware of this collection of resources upon which much of this content was built on.

[SECURITY.md](https://github.com/cncf/tag-security/blob/main/community/resources/project-resources/templates/SECURITY.md)
    draft security file that outlines subscribing to security bulletins, how to report issues, and supported versions.
[SECURITY_CONTACTS.md](https://github.com/cncf/tag-security/blob/main/community/resources/project-resources/templates/SECURITY_CONTACTS.md)
    a draft security contacts file to allow potential issue submitters to know who they can expect to hear from or how to follow up on issues.
[ISSUE_TEMPLATE.md](https://github.com/cncf/tag-security/blob/main/community/resources/project-resources/templates/ISSUE_TEMPLATE.md)
    a draft issue template to remind issue submitters that potential vulnerabilities do not get submitted as issues.
[incident-response.md](https://github.com/cncf/tag-security/blob/main/community/resources/project-resources/templates/incident-response.md)
    a draft, detailed incident response plan that covers how to triage issues, confirm vulnerabilities, leverage security advisories, and push a patch/release.
[embargo-policy.md](https://github.com/cncf/tag-security/blob/main/community/resources/project-resources/templates/embargo-policy.md)
    a draft embargo policy that outlines the time frame and conditions surrounding disclosures.
[embargo.md](https://github.com/cncf/tag-security/blob/main/community/resources/project-resources/templates/embargo.md)
    a draft embargo notification that details the contents a notification should contain.

Disclaimer: These resources are designed to be helpful to projects and organizations, they require customization and configuration by the project intending to use them. It does not prevent security issues from being found on a project, will not automatically resolve them, and does not place CNCF Security TAG as the responsible party. If changes are made to these templates, projects are not required to pull in a new update.

[dstebila]

Thanks @TheFoxAtWork for the helpful resources!

[dstebila]

A few notes from the security response discussion of the November 5 TSC meeting:

• Volunteers for security response team: Brian, Basil, Michael, Spencer, Pravek, Douglas
• Some key ideas in triaging an incident:
  • Identify someone to take ownership - should this be a rotating responsibility?
  • Assign technical lead - in the next status meeting?
  • Timeline of response
  • How to avoid dilution of ownership
  • How do we manage upstream vulnerabilities?

[baentsch]

How do we manage upstream vulnerabilities?

This question goes to the heart of what OQS wants to be: A place where "the buck stops" (i.e., responsibility is taken to fix things unconditionally, e.g., via the patch mechanism) or whether it keeps passing the buck to the many upstreams.

For the latter, OQS should have a clear classification of which upstreams are active (including getting clear ongoing upstream commitments to help with vulnerabilities at the same notice OQS may want to promise in its security policy) and those that are not. This classification would need to be clearly documented and utilized during incident handling.

For the former, OQS IMO would need to change its modus operandi upside down: From "best effort research code aggregator" to "reliable crypto code supplier". I personally have strong reservations about this being possible in the current setup.

Lastly, I'd like to re-iterate the thought stated a few months back:

• Do a "dry run" to see everyone knows what's to do (and ideally even do and document it :)

[dstebila]

Lastly, I'd like to re-iterate the thought stated a few months back:

* Do a "dry run" to see everyone knows what's to do (and ideally even do and document it :)

Yes, that's still on my to-do list as an action item from the last TSC call. However, we had also said that we would write up a security procedure, and I think it would make sense to have the procedure in place to work through during the dry-run, which is why I haven't asked Ry to help us do a dry run yet.

[SWilson4]

Here's a first attempt at a security procedure for OQS: #124