[openstack-dev] [kolla][tc] [security] threat analysis, tags, and the road ahead

Steven Dake (stdake) stdake at cisco.com
Thu Mar 31 19:44:02 UTC 2016

Including tc and kolla


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)


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
>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"
>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
>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.
>[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

More information about the OpenStack-dev mailing list