Open Stack

----- Original Message -----
> From: "Douglas Chivers" <doug.chivers at hp.com>
> To: openstack-security at lists.openstack.org
> Sent: Tuesday, June 10, 2014 9:54:37 PM
> Subject: [Openstack-security] OpenStack Security Vulnerability Impact Metrics
> 
> 
> To kick off the discussion of vulnerability metrics for OpenStack, I have
> taken a look at the two commonest vulnerability scoring frameworks, OWASP
> and CVSSv2, and looked over the relevant chapter in the security guide
> (http://docs.openstack.org/security-guide/content/ch012_configuration-manag
> ement.html).
> 
> 
> OWASP (https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) uses
> a fairly simple set of characteristics to define the risk of
> avulnerability. The Likelihood of the risk is calculated based on factors
> such as the ease of discovery and exploitation of the vulnerability, and
> the skill, motive and opportunity of the threat actor. The Technical
> Impact of the risk is calculated separately from the Business Impact of
> the risk, where the Technical Impact is based on loss of confidentiality,
> availability, integrity and accountability(?!) and business impact is
> based on financial and reputational damage and compliance violations.
> OWASP gives impacts for each of these categories, with an associated
> score. These are averaged to come up with likelihood, technical and
> business risk - the relevance of the technical or business risk is decided
> by the reviewer based on the scenario.
> 
> CVSS (http://www.first.org/cvss/cvss-guide#i1.1) calculates a metric based
> on three sets of metrics: Base Metrics, which are the fundamental
> characteristics of the vulnerability, Temporal Metrics, which are
> characteristics that change over time, and Environmental Metrics, which
> are dependant on a user¹s specific environment. The characteristics, such
> as ŒAccess Complexity¹, ŒAuthentication Required¹, have sets of specific
> answers, as for OWASP. Each answer has a specific score associated with
> it, which are combined to calculate the CVSS score.
> 
> The Security Guide has a brief section under Triage, for vulnerability
> assessment, which bases a Critical/High/Medium/Low score on a combination
> of vulnerability type and attacker location. The metric uses a limited set
> of vulnerabilities: Information Disclosure, Denial of Service and
> Privilege Elevation.
> 
> 
> 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.
> 
> 
> 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.
> 
> - 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¹.
> 
> 
> Any thoughts? I suggest we flesh out the requirements before diving into
> designing a methodology, but I¹m open to suggestions.


Hi Doug, 

Great work! 

I just thought I'd share how Red Hat currently classifies vulnerabilities: 

https://access.redhat.com/site/security/updates/classification/

We are currently applying CVSS2 scores and impact classifications to our OpenStack offerings. 
An example is here: 

https://rhn.redhat.com/errata/RHSA-2014-0455.html

As you mentioned CVSS2 doesn't really make a whole heap of sense for OpenStack but FWIW
the impact Red Hat assigns is not always directly derived from CVSS2 score. And whilst I 
agree we need a repeatable and objective process here I will also like to note that in
my experience these scoring systems don't always capture all the edge cases. So IMO having a 
mechanism that gives the VMT the discretion to bump up the impact of a vulnerability based
on the situation is probably something worth considering. 

On a (kind of) related topic: I would like to start including the classification of the underlying
flaw in our advisories. Something similar to CWE maybe? From a metrics perspective I would 
find this more useful for driving proactive initiatives to prevent recurrences. 

- Grant 

> 
> Doug
> 
> _____________________
> Doug Chivers
> HP Security Architect
> doug.chivers at hp.com
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>