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

Clark, Robert Graham robert.clark at hpe.com
Tue Apr 12 17:53:16 UTC 2016


On 12/04/2016 18:37, "Jeremy Stanley" <fungi at yuggoth.org> wrote:



>On 2016-04-01 15:50:57 +0000 (+0000), Hayes, Graham wrote:
>> 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?
>> 
>> I ask, as Designate looks like it meets nearly  all the current
>> requirements - the only outstanding question in my mind was the
>> Threat Analysis
>
>Seems fine to me, though in the interest of openness that
>documentation should probably be licensed such that it can be
>published somewhere for the whole community to read (once any
>glaring deficiencies are addressed anyway).
>-- 
>Jeremy Stanley

In some cases this may be feasible, in others less so. TA in general
tends to be implementation specific which is why, when discussing how
the Security Project would be performing TA work within OpenStack we
decided that it should be reflective of a best-practice deployment for
whatever project was being evaluated.[1][2]

There are two OpenStack vendors I know of that do in depth functional
threat analysis on OpenStack projects. I have been highly involved in
the development of TA at HPE and various colleagues in the Security
project have been involved with the TA process at Rackspace. When
evaluating our documentation sets together at the mid-cycle[2] it was
felt that in both cases, some degree of "normalization" would need to be
performed before either of us would be ready to share these documents
externally.

-Rob [Security]

[1] https://openstack-security.github.io/collaboration/2016/01/16/threat-analysis.html
[2] https://openstack-security.github.io/threatanalysis/2016/02/07/anchorTA.html
[3] https://openstack-security.github.io/mid-cycle/2016/01/15/mitaka-midcycle.html





More information about the OpenStack-dev mailing list