Jeremy hit all the major points there. What we do is basically model things based on a best-practice use case, we rely on the project to make good choices in this regard with a view to configurations, protocols etc.
Then we conduct an asset-oriented threat review, during which we create documentation that looks a lot like https://review.openstack.org/#/c/357978/5 It's not overly heavyweight and provides us with enough information to make some reasonably in-depth judgements and provide advice on areas where a project might have some weaknesses in design or implementation. A good first step is to say hello during one of our IRC meetings, 1700 UTC on #openstack-meeting-alt Cheers -Rob On Thu, Sep 1, 2016 at 4:38 PM, Ben Swartzlander <b...@swartzlander.org> wrote: > Thanks fungi. I misunderstood the full scope of the requirements for > vulnerability management and since we don't yet have volunteers willing to > perform all the required duties, I'm going to withdraw the tag request. > > As soon as interested community members step up to take on the > responsibilities I'll reapply for the tag. > > -Ben Swartzlander > > > > On 08/30/2016 01:07 PM, Jeremy Stanley wrote: > >> Ben has proposed[1] adding manila, manila-ui and python-manilaclient >> to the list of deliverables whose vulnerability reports and >> advisories are overseen by the OpenStack Vulnerability Management >> Team. This proposal is an assertion that the requirements[2] for the >> vulnerability:managed governance tag are met by these deliverables. >> As such, I wanted to initiate a discussion evaluating each of the >> listed requirements to see how far along those deliverables are in >> actually fulfilling these criteria. >> >> 1. All repos for a covered deliverable must meet the criteria or >> else none do. Easy enough, each deliverable has only one repo so >> this isn't really a concern. >> >> 2. We need a dedicated point of contact for security issues. Our >> typical point of contact would be a manila-coresec team in >> Launchpad, but that doesn't exist[3] (yet). Since you have a fairly >> large core review team[4], you should pick a reasonable subset of >> those who are willing to act as the next line of triage after the >> VMT hands off a suspected vulnerability report under embargo. You >> should have at least a couple of active volunteers for this task so >> there's good coverage, but more than 5 or so is probably pushing the >> bounds of information safety. Not all of them need to be core >> reviewers, but enough of them should be so that patches proposed as >> attachments to private bugs can effectively be "pre-approved" in an >> effort to avoid delays merging at time of publication. >> >> 3. The PTL needs to agree to act as a point of escalation or >> delegate this responsibility to a specific liaison. This is Ben by >> default, but if he's not going to have time to serve in that role >> then he should record a dedicated Vulnerability Management Liaison >> in the CPLs list[5]. >> >> 4. Configure sharing[6][7][8] on the defect trackers for these >> deliverables so that OpenStack Vulnerability Management team >> (openstack-vuln-mgmt) has "Private Security: All". Once the >> vulnerability:managed tag is approved for them, also remove the >> "Private Security: All" sharing from any other teams (so that the >> VMT can redirect incorrectly reported vulnerabilities without >> prematurely disclosing them to manila reviewers). >> >> 5. Independent security review, audit, or threat analysis... this is >> almost certainly the hardest to meet. After some protracted >> discussion on Kolla's application for this tag, it was determined >> that projects should start supplying threat analyses to a central >> security-analysis[9] repo where they can be openly reviewed and >> ultimately published. No projects have actually completed this yet, >> but there is some process being finalized by the Security Team which >> projects will hopefully be able to follow. You may want to check >> with them on the possibility of being an early adopter for that >> process. >> >> 6. Covered deliverables need tests we can rely on to be able to >> evaluate whether privately proposed security patches will break the >> software. A cursory look shows many jobs[10] running in our upstream >> CI for changes to these repos, so that requirement is probably >> addressed (I did not yet check whether those >> unit/functional/integration tests are particularly extensive). >> >> So in summary, it looks like there are still some outstanding >> requirements not yet met for the vulnerability:managed tag but I >> don't see any insurmountable challenges there. Please let me know if >> any of the above is significantly off-track. >> >> [1] https://review.openstack.org/350597 >> [2] https://governance.openstack.org/reference/tags/vulnerabilit >> y_managed.html#requirements >> [3] https://launchpad.net/~manila-coresec >> [4] https://review.openstack.org/#/admin/groups/213,members >> [5] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Vulnera >> bility_management >> [6] https://launchpad.net/manila/+sharing >> [7] https://launchpad.net/manila-ui/+sharing >> [8] https://launchpad.net/pythonmanilaclient/+sharing >> [9] https://git.openstack.org/cgit/openstack/security-analysis/ >> tree/doc/source/templates/ >> [10] https://git.openstack.org/cgit/openstack-infra/project-confi >> g/tree/zuul/layout.yaml >> >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev