Open Stack

I’m glad you’re chiming in Matt, you had some interesting ideas on this a few summits back. I did a breakdown of OSSA’s at the last summit and found that I’m largely in agreement with the points you’ve made below.  Ideally we want to be in a position where we can run typical analytics etc on OSSAs.

 

+1 to OWASP, Doug was providing somewhat of a literature review.

 

CVSSv3 was supposed to take virtualized environments into account but that’s never become an actual thing.

 

From: matt [mailto:matt at nycresistor.com] 
Sent: 10 June 2014 15:37
To: Tristan Cacqueray
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] OpenStack Security Vulnerability Impact Metrics

 

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 <mailto: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 <mailto: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/20140612/10ff6c26/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140612/10ff6c26/attachment.bin>