Open Stack

Graham,

Responses inline.

On 4/1/16, 8:50 AM, "Hayes, Graham" <graham.hayes at hpe.com> wrote:

>>> On 3/31/16, 12:15 PM, "michael mccune" <msm at redhat.com> wrote:
>>>
>>>> <snip>
> >>>
>>>> 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.
>>>>
>>>> <snip>
>>>>
>
>If a team has already done a TA (e.g. as part of an internal product
>TA) (and produced all the documentation) would this meet the
>requirements?

The governance repository will be worded as such to permit a TA to be done
by the project team or a competent third party.  (The third party in this
case being the internal product TA that most companies already have in
place).  I think the TA would have to be made public however, such that we
can audit the threat analysis as a community.

Perhaps the security team needs a repository containing the threat
analysis documents for various projects to be published on docs.oo.

Does that solve your concerns?
>
>I ask, as Designate looks like it meets nearly  all the current
>requirements - the only outstanding question in my mind was the
>Threat Analysis
>
>>>> [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.ht
>>>>ml
>>>>
>>>> [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
>> 
>>_________________________________________________________________________
>>_
>> 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