Open Stack

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140610/187d4443/attachment.sig>