Open Stack

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)" <stdake at 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" <msm at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev