<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>+1 to OWASP, Doug was providing somewhat of a literature review.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>CVSSv3 was supposed to take virtualized environments into account but that’s never become an actual thing.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> matt [mailto:matt@nycresistor.com] <br><b>Sent:</b> 10 June 2014 15:37<br><b>To:</b> Tristan Cacqueray<br><b>Cc:</b> openstack-security@lists.openstack.org<br><b>Subject:</b> Re: [Openstack-security] OpenStack Security Vulnerability Impact Metrics<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><div><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>I started making an attempt to role our vulnerability reporting into a more useful format two summits ago with this: <a href="https://github.com/openfly/openstack/blob/master/vulnerabilities/apr_2013/vulndb.json">https://github.com/openfly/openstack/blob/master/vulnerabilities/apr_2013/vulndb.json</a><o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>Any attempt to quantify risk for OpenStack starts with the collection of data, and the presentation of that data in a usable format.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>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.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>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.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>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.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>I'd be down to collaborate on putting our vulnerability metrics together into a more usable format. Whatever we believe that to be.<o:p></o:p></p></div><p class=MsoNormal>-Matt Joyce<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Jun 10, 2014 at 10:27 AM, Tristan Cacqueray <<a href="mailto:tristan.cacqueray@enovance.com" target="_blank">tristan.cacqueray@enovance.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal>Hi Doug,<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><br>On 06/10/2014 07:54 AM, Chivers, Douglas wrote:<br>><br>> Neither OWASP nor CVSS are cloud-aware, and the method described in the<br>> security guide is very basic, so clearly none of the three is an off the<br>> shelf solution. Due to the complexity of the maths involved in calculating<br>> the CVSS score I would consider extending OWASP so it is applicable to<br>> common cloud deployments.<br>><o:p></o:p></p></div><p class=MsoNormal>Many thanks for this very nice summary, and it is what we (the VMT) also<br>found out: we don't want to spend that much time on complexity<br>calculation that might even not apply correctly for OpenStack.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><br><br>><br>> Before we try and define a framework for vulnerability assessment, I<br>> suggest we make sure the requirements are clearly defined, here are a few:<br>><br>> - Define ŒThreat¹, ŒRisk¹, ŒVulnerability, etc - threat and risk are often<br>> used interchangeably, and do not appear to be defined in the security<br>> guide.<br>><o:p></o:p></p></div><p class=MsoNormal>Doesn't the impact description already cover those ? Maybe we could<br>formalize those. Several project break down the description in different<br>parts, e.g. FreeBSD:<br> 1 Background,<br> 2 Problem description<br> 3 Impact<br> 4 Workaround<br><br>Xen is doing this kind of breakdown:<br> 1 Issue description<br> 2 Impact<br> 3 Vulnerable systems<br> 4 Mitigation<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><br><br>> - The Vulnerability framework should include position in cloud in the<br>> calculation, e.g. Œunder cloud infrastructure¹, Œon cloud infrastructure¹,<br>> Œpublic instance¹<br>><br>> - The Vulnerability framework should include factor for type of<br>> deployment, e.g. Œprivate¹, Œpublic¹, Œtrusted¹, Œuntrusted¹, or maybe<br>> Œpaas¹ Œiaas¹.<br>><o:p></o:p></p></div><p class=MsoNormal>That is indeed something to think about as Openstack usage can be so<br>different, but then it can also be a great source of confusion. Some<br>bugs are indeed much more critical for public instance than under cloud<br>users, but most advisory are impacting all usage.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><br><br>><br>> Any thoughts? I suggest we flesh out the requirements before diving into<br>> designing a methodology, but I¹m open to suggestions.<br>><o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>It would be great if we could take into account the ease of<br>exploitation. Thinking about OSSA 2014-012 (Remote code execution in<br>Glance Sheepdog backend) it could have use a "Fix this asap" red light<br>compared to other bugs that are more specifics, hard to exploit, like<br>the ones that requires social engineering.<br><br>Best regards,<br>Tristan<br><br><br>_______________________________________________<br>Openstack-security mailing list<br><a href="mailto:Openstack-security@lists.openstack.org">Openstack-security@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security</a><o:p></o:p></p></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>