Draft: OQS security response process #124
Conversation
Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
SWilson4
force-pushed
the
sw-security-processes
branch
from
ffad71c to
746fb6e
Compare
|
|
||
| COMMENT: | ||
| We should confirm that all of the members of the VMT | ||
| (1) receive some sort of notification when a GitHub security advisory is filed on any OQS repo and (2) have the necessary permissions to view security advisories. |
There was a problem hiding this comment.
"any OQS repo" -- No. Suggest to agree on a subset. Ideally only those with a diverse, active contributor base which can play ball, err, handle problems (to stay in the picture, there should be more linebackers for that project than quarterbacks)
There was a problem hiding this comment.
We haven't enabled vulnerability reporting on all OQS repositories. So really this can be turned into a point about only turning on security vulnerability reporting on repositories that we have a sufficient base to support.
There was a problem hiding this comment.
What I meant (and probably should have clarified) was that we should make sure we're aware of all vulnerability reports, whichever repo they're filed on. For instance, if we have security advisories enabled for oqs-demos, it's possible we'll receive a report there that is pertinent to liboqs, even though (I imagine) we won't offer any sort of security policy for the demos.
| Pravek is now the Quarterback for the report. | ||
|
|
||
| COMMENT: | ||
| Do we want to commit to a reponse timeline? |
There was a problem hiding this comment.
Yes. But with the proposed "up next" approach, this cannot be guaranteed, depending on priorities, travel plans or other shenanigans.. I'd thus propose that the rotation changes by time (as and when a person is certain to be responsive) not by event ("up next").
There was a problem hiding this comment.
I see your point Michael. I think it would be important to make sure the quarterback knows that they're on duty. This could be done by a schedule (say, monthly; with an email coming from me at the start of each month letting them know they're on duty) or it could be that the one of the tasks of the quarterback is to pass the baton to the next quarterback by emailing them once the current quarterback is activated for an issue.
There was a problem hiding this comment.
If we go for a time-based rotation, we could do a 5-week cadence and "pass the baton" at TSC meetings (all of the current VMT regularly attends those).
I proposed the "up next" approach mostly to distribute work in the event that we receive two or three reports in a short time span.
| The Quarterback identifies the person or people who are most qualified to assess the report and, if necessary, develop a fix. | ||
| The Quarterback provides them with all necessary information. | ||
| These domain experts may not be members of the VMT, but they should be people whom the VMT trusts to handle security-related information. | ||
| It is possible that the Quarterback will also be the team member who is most qualified to assess the issue. In this case, the Quarterback may request that the "up next" member of the VMT assume the role of Quarterback, allowing the original Quarterback to focus on the technical aspects of the response process. |
There was a problem hiding this comment.
Doesn't that make matters even more complicated? Instead of focusing on the issue, the Quarterback is to be exchanged? To stay in the picture, why shouldn't the QB be allowed to run towards the end zone? Admitted, if there's a strong defense, not advisable -- but for OQS there's hardly anyone on the playing field.
There was a problem hiding this comment.
My intention was to potentially speed up the response process by separating management and technical responsibilities, so that the QB doesn't get swamped (especially if we go with a time-based rotation and the same person is handling multiple reports concurrently). Note that it's an optional swap and the original QB would still be involved: they would just be focusing solely on remediation development as opposed to managing the response process.
There was a problem hiding this comment.
Same thought as just voiced elsewhere: Are we overdoing things here? We have received how many security reports, exactly? We have how many players on the field? My gut feeling is that the work on "security issues" is going to go down from here as more and more serious(ly supported) software packages include PQC and current OQS users with a need for reliable (read: paid-for) software maintenance will accordingly switch over to such packages.
I'd thus suggest to no over-engineer things here: What about adding simple wording like "members of the VMT agree to be available to support each other on short notice if the need arises" for any "unforeseen issue" (like overload or whatever else)?
| Whether or not a security release is required is left to the discretion of the VMT. | ||
|
|
||
| COMMENT: | ||
| Apart from publishing the security advisory, should we publicize the fix in any other way? |
There was a problem hiding this comment.
On the OQS website we have some text saying that people can email me to request to be added to a security notification list. Is this something we should continue?
There was a problem hiding this comment.
I think it's a good idea—not everybody uses GitHub.
There was a problem hiding this comment.
we have some text saying that people can email me to request to be added to a security notification list.
No, the text says that an email should be sent to the same "security@" email address: This warrants two questions: 1) Did you create such list (and do you want to keep maintaining it), @dstebila and 2) should this wording be retained (or a split done into a reporting email address (that all of VMT receives) and a "interested party registration" email list (that only people subscribing to things like GDPR receive)?
not everybody uses GitHub
Agreed. So having such mechanism is "nice and kind" -- but comes at a cost (e.g., documenting it here, on the website and then "living" it)... I'm afraid we're overdoing things here: A company taking money for its software of course does this, but this is a completely non-committal project entirely without funding for people doing actual work or chores like this.
Signed-off-by: Spencer Wilson <spencer.wilson@uwaterloo.ca>
This PR proposes a security response process for OQS. Please read it over and provide feedback. I expect it will undergo a fair bit of revision, but hopefully this gives us a starting point.
I have left a number of comments requesting feedback on specific points throughout the document. These are clearly marked by COMMENT. I'll keep the PR in draft until all of these are removed.
Closes #60.