Open Stack

Jeremy hit all the major points there.

What we do is basically model things based on a best-practice use case, we
rely on the project to make good choices in this regard with a view to
configurations, protocols etc.

Then we conduct an asset-oriented threat review, during which we create
documentation that looks a lot like
https://review.openstack.org/#/c/357978/5

It's not overly heavyweight and provides us with enough information to make
some reasonably in-depth judgements and provide advice on areas where a
project might have some weaknesses in design or implementation.

A good first step is to say hello during one of our IRC meetings, 1700 UTC
on #openstack-meeting-alt

Cheers
-Rob

On Thu, Sep 1, 2016 at 4:38 PM, Ben Swartzlander <ben at swartzlander.org>
wrote:

> Thanks fungi. I misunderstood the full scope of the requirements for
> vulnerability management and since we don't yet have volunteers willing to
> perform all the required duties, I'm going to withdraw the tag request.
>
> As soon as interested community members step up to take on the
> responsibilities I'll reapply for the tag.
>
> -Ben Swartzlander
>
>
>
> On 08/30/2016 01:07 PM, Jeremy Stanley wrote:
>
>> Ben has proposed[1] adding manila, manila-ui and python-manilaclient
>> to the list of deliverables whose vulnerability reports and
>> advisories are overseen by the OpenStack Vulnerability Management
>> Team. This proposal is an assertion that the requirements[2] for the
>> vulnerability:managed governance tag are met by these deliverables.
>> As such, I wanted to initiate a discussion evaluating each of the
>> listed requirements to see how far along those deliverables are in
>> actually fulfilling these criteria.
>>
>> 1. All repos for a covered deliverable must meet the criteria or
>> else none do. Easy enough, each deliverable has only one repo so
>> this isn't really a concern.
>>
>> 2. We need a dedicated point of contact for security issues. Our
>> typical point of contact would be a manila-coresec team in
>> Launchpad, but that doesn't exist[3] (yet). Since you have a fairly
>> large core review team[4], you should pick a reasonable subset of
>> those who are willing to act as the next line of triage after the
>> VMT hands off a suspected vulnerability report under embargo. You
>> should have at least a couple of active volunteers for this task so
>> there's good coverage, but more than 5 or so is probably pushing the
>> bounds of information safety. Not all of them need to be core
>> reviewers, but enough of them should be so that patches proposed as
>> attachments to private bugs can effectively be "pre-approved" in an
>> effort to avoid delays merging at time of publication.
>>
>> 3. The PTL needs to agree to act as a point of escalation or
>> delegate this responsibility to a specific liaison. This is Ben by
>> default, but if he's not going to have time to serve in that role
>> then he should record a dedicated Vulnerability Management Liaison
>> in the CPLs list[5].
>>
>> 4. Configure sharing[6][7][8] on the defect trackers for these
>> deliverables so that OpenStack Vulnerability Management team
>> (openstack-vuln-mgmt) has "Private Security: All". Once the
>> vulnerability:managed tag is approved for them, also remove the
>> "Private Security: All" sharing from any other teams (so that the
>> VMT can redirect incorrectly reported vulnerabilities without
>> prematurely disclosing them to manila reviewers).
>>
>> 5. Independent security review, audit, or threat analysis... this is
>> almost certainly the hardest to meet. After some protracted
>> discussion on Kolla's application for this tag, it was determined
>> that projects should start supplying threat analyses to a central
>> security-analysis[9] repo where they can be openly reviewed and
>> ultimately published. No projects have actually completed this yet,
>> but there is some process being finalized by the Security Team which
>> projects will hopefully be able to follow. You may want to check
>> with them on the possibility of being an early adopter for that
>> process.
>>
>> 6. Covered deliverables need tests we can rely on to be able to
>> evaluate whether privately proposed security patches will break the
>> software. A cursory look shows many jobs[10] running in our upstream
>> CI for changes to these repos, so that requirement is probably
>> addressed (I did not yet check whether those
>> unit/functional/integration tests are particularly extensive).
>>
>> So in summary, it looks like there are still some outstanding
>> requirements not yet met for the vulnerability:managed tag but I
>> don't see any insurmountable challenges there. Please let me know if
>> any of the above is significantly off-track.
>>
>> [1] https://review.openstack.org/350597
>> [2] https://governance.openstack.org/reference/tags/vulnerabilit
>> y_managed.html#requirements
>> [3] https://launchpad.net/~manila-coresec
>> [4] https://review.openstack.org/#/admin/groups/213,members
>> [5] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Vulnera
>> bility_management
>> [6] https://launchpad.net/manila/+sharing
>> [7] https://launchpad.net/manila-ui/+sharing
>> [8] https://launchpad.net/pythonmanilaclient/+sharing
>> [9] https://git.openstack.org/cgit/openstack/security-analysis/
>> tree/doc/source/templates/
>> [10] https://git.openstack.org/cgit/openstack-infra/project-confi
>> g/tree/zuul/layout.yaml
>>
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/e3072401/attachment.html>