Open Stack

I started making an attempt to role our vulnerability reporting into a more
useful format two summits ago with this:
https://github.com/openfly/openstack/blob/master/vulnerabilities/apr_2013/vulndb.json

Any attempt to quantify risk for OpenStack starts with the collection of
data, and the presentation of that data in a usable format.

Today, we really don't have vulnerability information for OpenStack in a
usable format.  We also need to discuss the mechanism by which we will
endeavour to collect information on actual exploitation of openstack
adopters.

I think that discussion is what we'd need to focus on before we can come up
with a risk model.  Get us using the same tools on the same data, and we'll
have a much better time discussing which risk assessment model is right for
OpenStack.

As stated earlier, OWASP's risk metrics are based on the threat profile of
web applications.  This is well and good for horizon, but it wouldn't
address the most damning vulnerabilities we've seen in keystone or the
primacy of a hypervisor escape vulnerability in any threat matrix.

I'd be down to collaborate on putting our vulnerability metrics together
into a more usable format.  Whatever we believe that to be.

-Matt Joyce


On Tue, Jun 10, 2014 at 10:27 AM, Tristan Cacqueray <
tristan.cacqueray at enovance.com> wrote:

> Hi Doug,
>
> On 06/10/2014 07:54 AM, Chivers, Douglas wrote:
> >
> > Neither OWASP nor CVSS are cloud-aware, and the method described in the
> > security guide is very basic, so clearly none of the three is an off the
> > shelf solution. Due to the complexity of the maths involved in
> calculating
> > the CVSS score I would consider extending OWASP so it is applicable to
> > common cloud deployments.
> >
>
> Many thanks for this very nice summary, and it is what we (the VMT) also
> found out: we don't want to spend that much time on complexity
> calculation that might even not apply correctly for OpenStack.
>
>
> >
> > Before we try and define a framework for vulnerability assessment, I
> > suggest we make sure the requirements are clearly defined, here are a
> few:
> >
> > - Define ŒThreat¹, ŒRisk¹, ŒVulnerability, etc - threat and risk are
> often
> > used interchangeably, and do not appear to be defined in the security
> > guide.
> >
>
> Doesn't the impact description already cover those ? Maybe we could
> formalize those. Several project break down the description in different
> parts, e.g. FreeBSD:
>  1 Background,
>  2 Problem description
>  3 Impact
>  4 Workaround
>
> Xen is doing this kind of breakdown:
>  1 Issue description
>  2 Impact
>  3 Vulnerable systems
>  4 Mitigation
>
>
> > - The Vulnerability framework should include position in cloud in the
> > calculation, e.g. Œunder cloud infrastructure¹, Œon cloud
> infrastructure¹,
> > Œpublic instance¹
> >
> > - The Vulnerability framework should include factor for type of
> > deployment, e.g. Œprivate¹, Œpublic¹, Œtrusted¹, Œuntrusted¹, or maybe
> > Œpaas¹ Œiaas¹.
> >
>
> That is indeed something to think about as Openstack usage can be so
> different, but then it can also be a great source of confusion. Some
> bugs are indeed much more critical for public instance than under cloud
> users, but most advisory are impacting all usage.
>
>
> >
> > Any thoughts? I suggest we flesh out the requirements before diving into
> > designing a methodology, but I¹m open to suggestions.
> >
>
> It would be great if we could take into account the ease of
> exploitation. Thinking about OSSA 2014-012 (Remote code execution in
> Glance Sheepdog backend) it could have use a "Fix this asap" red light
> compared to other bugs that are more specifics, hard to exploit, like
> the ones that requires social engineering.
>
> Best regards,
> Tristan
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140610/b7aea797/attachment.html>