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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
