Thanks Steve, Mike, We’ve had a lot more traction with this latest incarnation of TA. I’m very much looking forward to working through the process with the wider community.
-Rob On 31/03/2016 20:44, "Steven Dake (stdake)" <std...@cisco.com> wrote: >Including tc and kolla > >Michael, > >Sounds good. I'll get the governance changes rolling for debate at the >next TC meeting. > >Note I added this cross project topic for discussion Tuesday at summit >(last item in the list) >https://etherpad.openstack.org/p/newton-cross-project-sessions > >Regards, >-steve > >On 3/31/16, 12:15 PM, "michael mccune" <m...@redhat.com> wrote: > >>hey all, >> >>at the most recent ossp meeting[1], there was some extended discussion >>about threat analysis and the work that is being done to push this >>forward. >> >>in this discussion, there were several topics brought up around the >>process for doing these analyses on current projects and how the ossp >>should proceed especially with respect to the "vulnerability:managed" >>tag[2]. >> >>as for the threat analysis process, there are still several questions >>which need to be answered: >> >>* what is the process for performing an analysis >> >>* how will an analysis be formally recognized and approved >> >>* who will be doing these analyses >> >>* does it make sense to keep the analysis process strictly limited to >>the vmt >> >>* how to address commonalities and differences between a developer >>oriented analysis and a deployer oriented analysis >> >>these questions all feed into another related topic, which is the >>proposed initial threat analysis for kolla which has been suggested to >>start at the upcoming austin summit. >> >>i wanted to capture some of the discussion happening around this topic, >>and continue the ball rolling as to how we will solve these questions as >>we head to summit. >> >>one of the big questions seems to be who should be doing these analysis, >>especially given that the ossp has not formally codified the practice >>yet, and the complexity involved. although currently the >>vulnerability:managed tag suggests that a third party review should be >>done, this may prove difficult to scale in practice. i feel that it >>would be in the best interests of the wider openstack community if the >>ossp works towards creating instructional material that can empower the >>project teams to start their own analyses. >> >>ultimately, having a third-party review of a project is worthy goal, but >>this has to be tempered with the reality that a single team will not be >>able to scale out and provide thorough analyses for all projects. to >>that extent, the ossp should work, initially, to help a few teams get >>these analyses completed and in the process create a set of useful tools >>(docs, guides, diagrams, foil-hat wearing pamphlets) to help further the >>effort. >> >>i would like to propose that the threat analysis portion of the >>vulnerability:managed tag be modified with the goal of having the >>project teams create their own analyses, with an extended third-party >>review to be performed afterwards. in this respect, the scale issue can >>be addressed, as well as the issue of project domain knowledge. it makes >>much more sense to me to have the project team creating the initial work >>here as they will know the areas, and architectures, that will need the >>most attention. >> >>as the ossp build better tools for generating these analyses they will >>be in a much better position to guide project teams in their initial >>analyses, with the ultimate goal of having the ossp, and/or vmt, perform >>the third-party audit for application of the tag. i have a feeling we >>will also discover much overlap between the developer and deployer >>oriented analyses, and these overlaps will help to strengthen the >>process for all involved. >> >>finally, the austin summit, and proposed kolla review, provide a great >>opportunity for the ossp to put "rubber on the road" with respect to >>this process. although a full analysis may not be accomplished during >>the summit, we can definitely achieve the goal of defining this process >>much better and creating more guidance for all projects that wish to >>follow this path, as well as having kolla solidly on the way to having a >>full threat analysis ready for third-party review. >> >>thoughts? >> >> >>regards, >>mike >> >> >>[1]: >>http://eavesdrop.openstack.org/meetings/security/2016/security.2016-03-31- >>17.00.log.txt >> >>[2]: >>http://governance.openstack.org/reference/tags/vulnerability_managed.html >> >>[3]: https://review.openstack.org/#/c/220712/ >> >>__________________________________________________________________________ >>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 __________________________________________________________________________ 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