Tooling Requirements

[ran-dall]

At today's Section 3 meeting, the possibility of using VINCE (or possibly developing our vendor-agnostic tooling similar to VINCE) was discussed; however, the issue came up as to what we wanted to determine the requirements of said tooling solution.

I've opened this issue so the group may propose and document some of these requirements.

[TheFoxAtWork]

@SecurityCRob had some awesome suggestions on the call and he said he would capture many of them here.

[TheFoxAtWork]

Also recommend structuring/capturing this such that it could be a timeless blog post. Cover our use cases, threat concerns, collaboration and partnership needs.

[SecurityCRob]

My first round of SIRT IR tool requirements:

• the tool needs to be protected by strong access controls and multi-level authorization lists
• participants in IR event should be able to set read-in lists on a case-by-case basis and also globally set "for issues of type X (or involving software Y, always add Z")
• authorized users should be viewable by SIRT, reporters, and maintainers at all times. Downstream consumers allowed to participate in case may be allowed to see all participants at the discretion of the reporter and maintainer.
• the tool should be resilient against Denial of Service attacks and geographic outages
• the ability to privately & securely intake new issues & track them through IR lifecycle
• the ability to send encrypted messages to all involved stakeholders
• the ability to include additional participants in a case
• the ability to have both private comments for the SIRT, read-in parties, as well as "public" messages for downstream consumers engaged
• the ability to assign vuln identifiers (CVE, OSV, etc)
• the ability to denote disclosure outlets/channels to involved parties (e.g. "when public, this will be shared via mailing list, blog, OSV" or other applicable methods)
• the ability to generate advisories from case data and publish via assorted outputs (mailing list, CSAF, GH Advisory, OSV, etc.)
• the ability to assign issue severity, impact, and affectedness (VEX)
• all data in system should be encrypted at rest, in transit, and at use wherever applicable
• tool should be multi-cloud-able (e.g. it should be able to be run on any cloud or on-prem infrastructure and be portable as desired)
• tool needs multi-level access controls with MFA access to critical functions