<div dir="ltr"><div dir="ltr"><div>I understand the limitations and challenges of CVSS. We already do a lot of what you mentioned to come up with a risk score. Some of it, I'm still trying to figure out how to do. The bottom line though, is that we find the factors that go into the score (CIA, exploitability, exploit availability, attack vector, etc) to be useful. The score <i>itself</i>, is what I was talking about not being terribly useful, though it does go into our model also. After we run our prioritization engine, 10s turn into zeros, 5s become 10s and 3s become 7s or 8s on the risk scale. So, in our experience, some of the scoring is FAR from worst case and are much too conservative. Others are not conservative enough. Ultimately, we've found CVSS scoring to be no better than choosing at random and one of our competitors came to the same conclusion independently.</div><div><br></div><div>To summarize, the scoring process and components are useful to us. The resulting score, not so much - every piece of data we have from our research shows that it is consistently unreliable.</div><div><br></div><div>This is a great list of risk factors and we use many of them. Almost all of them are things we've discussed in depth or tried to automate in some way, so I'm going to get pedantic and comment on each, in the hopes that it clarifies how far down this road the industry has gone. Also, when I say "we", I'm generally referring to industry work in this area, what I do at my employer and what our competitors are doing.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 10, 2019 at 2:02 PM Monroe, Bruce <<a href="mailto:bruce.monroe@intel.com">bruce.monroe@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">







<div lang="EN-US">
<div class="gmail-m_7293801301951199177WordSection1">
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">Uh no. CVSS scores a vulnerability and if it’s a vendor we’re scoring that without knowing how you have the vulnerable software/firmware/hardware/<span class="gmail-m_7293801301951199177SpellE">ect</span>
 deployed in your environment. It’s why the CVSS Base Score is worst case. The resulting CVSS V3 vulnerability score is
<i>one</i> element you can then calculate into your overall risk factoring. It’s the orgs job consuming the CVSS V3x vulnerability score to determine their risk and set their patching priorities.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">Other Factors to consider for Risk (<i>not a comprehensive list but it’s a good start)<u></u><u></u></i></span></p>
<p class="MsoNormal"><i><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"><u></u> <u></u></span></i></p>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in">
<span style="font-family:"Book Antiqua",serif">Ease of exploit</span></li></ul></div></div></blockquote><div>Should the exploitability score not embody this? </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><span style="font-family:"Book Antiqua",serif">Delivery Mechanism (is the vuln available remotely over the network? Do have to have code running locally on the box (if so I’ve already got code running on the platform) The more access I need to the platform
 the less likely the issue is of being exploited in the wild.</span></li></ul></div></div></blockquote><div>This should also be part of the scoring (Attack Vector) and is one of the most frustrating and frequently misreported aspects of vulnerabilities. RCE and DoS are very different outcomes and it's generally one of the first things I have to go digging for when a big new vuln goes public.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><span style="font-family:"Book Antiqua",serif">Availability and sophistication level of exploit: Paper, PoC, weaponized exploit,
<span class="gmail-m_7293801301951199177SpellE">etc</span>…</span></li></ul></div></div></blockquote><div>This is the same as ease of exploit/exploitability, no? </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><b><span style="font-family:"Book Antiqua",serif">Detailed Asset knowledge</span></b><span style="font-family:"Book Antiqua",serif"> for the infrastructure and how vulnerable component is deployed.
<i>Hard to determine risk if you don’t know what you have and how you have systems deployed.</i></span></li></ul></div></div></blockquote><div>I've worked with enterprises of all sizes over almost 20 years and can say this is rarely going to happen. We're working on automated ways of addressing/solving this. RedSeal, Core Security and others tackled attack path mapping, but this should really be a feature of an enterprise vuln mgmt solution, not an entirely product to be purchased and managed separately.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><span style="font-family:"Book Antiqua",serif">Controls that would mitigate the attack vectors (firewalls, vulnerable component not exposed,
<span class="gmail-m_7293801301951199177SpellE">etc</span>…)</span></li></ul></div></div></blockquote><div> This is a Big Deal. I don't think we'll ever see a day where we can patch vulnerable components quick enough to satisfy risk goals, so there has to be some plan for mitigation in place - preferably one that works without requiring prior knowledge of the vulnerability details (mitigations that address entire attack classes, in other words).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><span style="font-family:"Book Antiqua",serif">Is your deployment actually exposing the vulnerability – (Example – you may have a library in your application but are not exposing or using the vulnerable function)</span></li></ul></div></div></blockquote><div>This can be addressed in a number of ways. The BAS market and EDR markets can help with this, for example. We've also experimented with doing validation using real exploits. What you can do is limited though, because many exploits aren't safe to run against production systems and "we run exploits in production" is generally a non-starter with a lot of orgs :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><span style="font-family:"Book Antiqua",serif">% of environment that is exposed, # of systems impacted, $ value of those systems in terms of keeping the business running.</span></li></ul></div></div></blockquote><div>Again, accurate, up-to-date asset management/inventory just doesn't exist most places and I'm not expecting that to change as long as it's a manual process to do it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><span style="font-family:"Book Antiqua",serif">Where are the impacted systems located, if a system has more than one interface choose the worst</span></li></ul></div></div></blockquote><div>Should be the same as the "Detailed Asset knowledge" example, no?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><span style="font-family:"Book Antiqua",serif">Are the impacted systems multi-homed (laptops, tablets, et al.) Do they live on your network and go home to an ISP that’s the wild west for malware for example.</span></li></ul></div></div></blockquote><div>Multi-homed means something different to me, but your point is a good one - systems that regularly alternate between untrusted and trusted networks should be managed and scored differently. Here begins a BeyondCorp/SDP conversation :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><span style="font-family:"Book Antiqua",serif">What are the bottom line consequence to your organization if this issue is successfully exploited (Think $$$$, potential impact to Brand, stock prices…).</span></li></ul></div></div></blockquote><div>Integration with DC/BCP/BIA/GRC and risk assessment output is probably necessary when we start getting into this stuff. Something you'd only see more mature orgs attempting (hi, Alex Hutton!)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><span style="font-family:"Book Antiqua",serif">What is the highest classification of information that could potentially be exposed? PII, Core IP, keys to the kingdom,…</span></li></ul></div></div></blockquote><div>DLP alone is hard and probably has the worst false positive challenge in the industry, but we've got to get there eventually. Agreed though - this is important, though I see it as a subset of setting that asset importance/criticality value, which could be dynamic, not just a static, "this is a server, so it gets a 7", score.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><span style="font-family:"Book Antiqua",serif">Business impact if issue is exploited <5 % of business impacted, 5-10% of business impacted, 10-25% of business impacted,…,</span></li></ul></div></div></blockquote><div>Another bullet to go under the BIA/GRC/Asset value heading. I think this is largely a different process altogether. It's a different set of people that worry about breach impact to the business as a whole, versus the analyst trying to figure out which vulnerability is most critical and should get some attention today.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><span style="font-family:"Book Antiqua",serif">Likelihood of exploit (put on your SWAMI hat here…</span><span style="font-family:"Segoe UI Emoji",sans-serif">😉</span><span style="font-family:"Book Antiqua",serif">)</span></li></ul></div></div></blockquote><div>We actually have a machine learning model for this. It's not too hard, when analyzing past vulns that have caused serious damages, to put together a recipe for what a future EternalBlue/MS08-067/Heartbleed will look like. No SWAMI hats needed, just some equations and a lot of data :) It would be funny if someone gave their data scientist the title of CHIEF SWAMI though.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><ul style="margin-top:0in" type="disc"><li class="gmail-m_7293801301951199177MsoListParagraph" style="color:rgb(31,73,125);margin-left:0in"><span style="font-family:"Book Antiqua",serif">If you ever see a network RCE that is exposed by default that’s a red flag.
<i>We don’t see too many of these today but there is still an occasional one.</i></span></li></ul></div></div></blockquote><div>You wouldn't think this would be so hard, but reading through the details of the Equifax breach, it's easy to see how it happens. In their case, they got the red flag, it was their ability to use technical tools to tie that red flag to something running in their environment that failed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">There needs to be significant thought put in to determine your orgs overall risk and what bubbles up to the top in terms of patching priority for typically limited resources to
 get those mitigations deployed. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">As mentioned CVSS vulnerability scores
<u>is a single data point</u> in making that assessment. I personally think we need a new tool, mechanism, that is an industry standard but that is beyond the scope of CVSS. While some improvements are planned for CVSS V4 this is a separate problem that needs
 to be solved outside of CVSS <span class="gmail-m_7293801301951199177SpellE">imo</span>.</span></p></div></div></blockquote><div><br></div><div>To summarize, we've built that tool and again, we don't just use the score as a single data point - the score components (e.g. AV:N/AC:L/Au:N/C:C/I:C/A:C/E:F/RL:OF/RC:C) are equally important. Personally, I'd rather see this problem solved at the CVE/CVSS level - it would be a lot easier and less expensive for everyone involved. Another idea I'm trying to get off the ground that wouldn't require as much effort on either end is crowdsourcing. Every time a new vulnerability comes out, thousands of analysts and pentesters analyze it and attempt to exploit/use it. If that knowledge could be collected anonymously and publicly shared, about half of the challenges you mention might go away.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">CVSS isn’t perfect but it’s pretty good at what it’s targeted to do. Use the right tool, if you need a hammer don’t try to use a screwdriver. If you’re using CVSS as the end all
 be all for Risk you’re using it wrong, it’s a single element to input into that overall calculation.</span></p></div></div></blockquote><div><br></div><div>After going through all this, I'm still unclear at what CVSS is targeted to do, or how you can declare that it's "pretty good" at it. What process are you using to determine the accuracy and/or quality of CVSS scores or the scoring system itself?</div><div><br></div><div>Looking at stats like <i>95% of CVEs rated as high have never been used maliciously</i> make it hard to agree with this statement. If 95% of vulnerabilities with a high score are found to be not vulnerable, I still have to question the efficacy of the scoring system.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7293801301951199177WordSection1"><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">Regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">Bruce<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">Opinions expressed are my own and may not reflect those of my employer.<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_7293801301951199177______replyseparator"></a><b><span>From:</span></b><span>
<span class="gmail-m_7293801301951199177SpellE">Dailydave</span> <<a href="mailto:dailydave-bounces@lists.immunityinc.com" target="_blank">dailydave-bounces@lists.immunityinc.com</a>> <b>
On Behalf Of </b>Adrian Sanabria<br>
<b>Sent:</b> Thursday, January 10, 2019 8:02 AM<br>
<b>To:</b> Wim <span class="gmail-m_7293801301951199177SpellE">Remes</span> <<a href="mailto:wremes@gmail.com" target="_blank">wremes@gmail.com</a>><br>
<b>Cc:</b> <a href="mailto:dailydave@lists.immunityinc.com" target="_blank">dailydave@lists.immunityinc.com</a><br>
<b>Subject:</b> Re: [<span class="gmail-m_7293801301951199177SpellE">Dailydave</span>] CVSS is the worst compression algorithm ever<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Okay, we keep touching on this point, that CVSS isn't intended to score risk, just vulnerability severity. I'm having a hard time seeing what value there is in having a vulnerability score that doesn't reflect risk. What use does it have?<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Or is that exactly what we're saying? That since it doesn't reflect risk, it's essentially useless. If that's the conclusion, I'm on the same page.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">--Adrian <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Jan 10, 2019, 9:56 AM Wim <span class="gmail-m_7293801301951199177SpellE">Remes</span> <<a href="mailto:wremes@gmail.com" target="_blank">wremes@gmail.com</a> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hi,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Bruce really hits the nail on the head here. CVSS != Risk. To broaden that discussion and not waste too many words, I’ll reference FAIR (Factor Analysis of Information Risk, <a href="https://www.fairinstitute.org/what-is-fair" target="_blank">https://www.fairinstitute.org/what-is-fair</a>)
 to indicate where “Vulnerability” contributes to an eventual quantitative risk valuation. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I also always considered CVSS scoring to be qualitative instead of quantitative and the numbers to be ordinal. That makes them fine for ranking vulnerability, but horrible to perform math on (Jet Fuel x Peanut Butter = Shiny — hi Alex Hutton!). <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">That said, it all boils down to a point I’ve been rapping on about for a long
<span class="gmail-m_7293801301951199177SpellE">long</span> time now. Organizations should not expect third party penetration testers to make an accurate assessment of risk. The data provided by a third party penetration tester should feed into your risk management framework, that is
 also fed with internally acquired business data, to produce (or adjust) a risk valuation. It would be helpful if we, as consultants, wouldn’t pretend that we (a) can come up with any form of credible risk score during such assessments and (b) are delivering
 scoring that can help with prioritization in a business context without additional effort on the client side. On the other hand, clients that have a risk management framework that can actually take vulnerability scores and use them to generate risk scores
 should be clear in what they expect from us. If you are asked, whether in an RFP or an SoW, to produce a risk score for your findings at the very least you should be returning a question for asset valuation and threat community descriptions. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Cheers,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Wim<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><br>
<u></u><br>
<u></u><u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">On 8 Jan 2019, at 18:33, Monroe, Bruce <<a href="mailto:bruce.monroe@intel.com" target="_blank">bruce.monroe@intel.com</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">Hi Dave,</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">I participate on the CVSS SIG being ran out of FIRST that is working on improvements to CVSS.<span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><span class="gmail-m_7293801301951199177m773332623209258761grame">So</span><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span>do
 a number of people out of CERT CC, NIST, MITRE along with a good representation of industry.<span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><span class="gmail-m_7293801301951199177m773332623209258761grame">A number of</span><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span>us
 provided feedback on this paper. CVSS is for scoring the severity of a vulnerability. CVSS does not = Risk.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">My understanding is there is<span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><span class="gmail-m_7293801301951199177m773332623209258761grame">a number of</span><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span>government
 entities that believe CVSS does = Risk and are using it in a vacuum for that purpose. While the CVSS score is a single component - you also must look at how the vulnerable component is deployed, controls in place, value of asset, patching windows, likelihood
 of <span class="gmail-m_7293801301951199177SpellE">exploit,<span class="gmail-m_7293801301951199177m773332623209258761spelle">ect</span></span>…there is a lot that goes into determining risk.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">The fact that various USG entities is using CVSS wrong is an education issue<span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><span class="gmail-m_7293801301951199177SpellE"><span class="gmail-m_7293801301951199177m773332623209258761spelle">imo</span></span>.<span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><span class="gmail-m_7293801301951199177m773332623209258761grame">Yes</span><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span>CVSS
 has it’s issues with some of<span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><span class="gmail-m_7293801301951199177m773332623209258761spelle">it’s</span><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span>elements being subjective eye of the beholder type
 items but that isn’t the reason for this paper…they’ve got USG people using it in a vacuum when it’s only a single element of determining your orgs risk due to a vulnerability. That isn’t a CVSS problem that’s a vulnerability management 101 problem.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">Regards,</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">Bruce</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">Intel PSIRT</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:rgb(31,73,125)">Opinions expressed are my own and may not reflect those of my employer.</span><u></u><u></u></p>
</div>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<div>
<p class="MsoNormal"><a name="m_7293801301951199177_m_773332623209258761______replyseparator"></a><b>From:</b><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><span class="gmail-m_7293801301951199177SpellE"><span class="gmail-m_7293801301951199177m773332623209258761spelle">Dailydave</span></span><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><<a href="mailto:dailydave-bounces@lists.immunityinc.com" target="_blank">dailydave-bounces@lists.immunityinc.com</a>><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><b>On
 Behalf<span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><span class="gmail-m_7293801301951199177m773332623209258761grame">Of</span><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span></b>Dave<span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><span class="gmail-m_7293801301951199177m773332623209258761spelle">Aitel</span><br>
<b>Sent:</b><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span>Tuesday, January 08, 2019 8:14 AM<br>
<b>To:</b><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><a href="mailto:dailydave@lists.immunityinc.com" target="_blank">dailydave@lists.immunityinc.com</a><br>
<b>Subject:</b><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span>[<span class="gmail-m_7293801301951199177SpellE"><span class="gmail-m_7293801301951199177m773332623209258761spelle">Dailydave</span></span>] CVSS is the worst compression algorithm ever<u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div id="gmail-m_7293801301951199177m_773332623209258761divtagdefaultwrapper">
<p><span style="font-size:12pt;font-family:Helvetica,sans-serif">I wanted to take a few minutes and do a quick highlight of a paper from CMU-CERT which I think most people have missed out on: <a href="https://resources.sei.cmu.edu/asset_files/WhitePaper/2018_019_001_538372.pdf" target="_blank"><span style="color:purple">https://resources.sei.cmu.edu/asset_files/WhitePaper/2018_019_001_538372.pdf</span></a></span><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u><u></u></span></p>
<div style="margin-bottom:15pt;overflow:auto" id="gmail-m_7293801301951199177m_773332623209258761LPBorder_GT_15469630031460.183622448101032">
<table class="gmail-m_7293801301951199177MsoNormalTable" border="1" cellspacing="0" cellpadding="0" width="90%" style="width:90%;background:white;border-top:1pt dotted rgb(200,200,200);border-left:none;border-bottom:1pt dotted rgb(200,200,200);border-right:none">
<tbody>
<tr>
<td valign="top" style="border:none;padding:0in">
<div id="gmail-m_7293801301951199177m_773332623209258761LPTitle_15469630031430.5656392074504">
<p class="MsoNormal" style="margin-top:15pt"><span style="font-size:16pt;font-family:"Segoe UI Light",sans-serif;color:rgb(105,9,139)"><a href="https://resources.sei.cmu.edu/asset_files/WhitePaper/2018_019_001_538372.pdf" target="_blank"><span style="color:purple;text-decoration:none">Towards
 Improving CVSS - resources.sei.cmu.edu</span></a></span><u></u><u></u></p>
</div>
<div style="margin-top:7.5pt;margin-bottom:12pt" id="gmail-m_7293801301951199177m_773332623209258761LPMetadata_15469630031440.623748296566867">
<p class="MsoNormal" style="margin-top:15pt;line-height:10.5pt"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:rgb(102,102,102)"><a href="http://resources.sei.cmu.edu" target="_blank">resources.sei.cmu.edu</a></span><u></u><u></u></p>
</div>
<div id="gmail-m_7293801301951199177m_773332623209258761LPDescription_15469630031450.5530823382524725">
<p class="MsoNormal" style="margin-top:15pt;line-height:15pt"><span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:rgb(102,102,102)">SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY REV-03.18.2016.0 Distribution Statement A: Approved
 for Public Release; Distribution Is Unlimited TOWARDS IMPROVING CVSS</span><u></u><u></u></p>
</div>
</td>
</tr>
</tbody>
</table>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">It's almost as funny a read as their previous best work on how "<a href="https://www.kb.cert.org/vuls/id/261869/" target="_blank"><span style="color:purple">clientless HTTPS VPNs are insanely dumb</span></a> what were
 you thinking omg?"<span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span></span><u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">They use a ton of big words in the paper to call CVSS out and give it a shellacking. Like most of you, we have extensive use of CVSS in our consulting practice and I've seen this stuff first hand. CVSS is
 of course just a buggy compression algorithm for taking complex qualitative data and then putting it on a number line. The paper has three angles here: </span><u></u><u></u></p>
</div>
</div>
<div>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal"><span style="font-size:12pt">Qualitative mappings into quantitative numbers are a silly thing to do, like people trying to do "social science" by using SurveyMonkey.</span><u></u><u></u></li><li class="MsoNormal"><span style="font-size:12pt">We're pretty sure that the compression algorithm is not, in fact, putting higher risk items as bigger numbers, which is the whole point of the thing.  </span><u></u><u></u></li><li class="MsoNormal"><span style="font-size:12pt">Nobody is applying this in any sort of consistent way (which is probably impossible) which is ALSO the whole point of the thing.</span><u></u><u></u></li></ol>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">It's fine to have a lossy compression algorithm that emphasizes certain aspects of the input signal over others, of course, but an additional CERT/CC critique is we have no reason to think CVSS does this in
 any useful way. </span><u></u><u></u></p>
</div>
<p><span style="font-size:12pt;font-family:Helvetica,sans-serif"> </span><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u><u></u></span></p>
<p><span style="font-size:12pt;font-family:Helvetica,sans-serif">There's<span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span><span class="gmail-m_7293801301951199177m773332623209258761grame">definitely people</span><span class="gmail-m_7293801301951199177m773332623209258761apple-converted-space"> </span>in
 the CVSS process (who I will avoid calling out by name) who think ANY quantization is good. But read the paper and decide for yourself - because these are probably serious issues that are turning your entire risk org into a Garbage-In-Garbage-Out org...</span><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u><u></u></span></p>
<p><span style="font-size:12pt;font-family:Helvetica,sans-serif"> </span><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u><u></u></span></p>
<p><span style="font-size:12pt;font-family:Helvetica,sans-serif">-<span class="gmail-m_7293801301951199177SpellE"><span class="gmail-m_7293801301951199177m773332623209258761spelle">dave</span></span></span><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u><u></u></span></p>
<p><span style="font-size:12pt;font-family:Helvetica,sans-serif"> </span><span style="font-size:9pt;font-family:Helvetica,sans-serif"><u></u><u></u></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Helvetica,sans-serif">_______________________________________________<br>
<span class="gmail-m_7293801301951199177SpellE">Dailydave</span> mailing list<br>
<a href="mailto:Dailydave@lists.immunityinc.com" target="_blank">Dailydave@lists.immunityinc.com</a><br>
<a href="https://lists.immunityinc.com/mailman/listinfo/dailydave" target="_blank">https://lists.immunityinc.com/mailman/listinfo/dailydave</a></span><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
<span class="gmail-m_7293801301951199177SpellE">Dailydave</span> mailing list<br>
<a href="mailto:Dailydave@lists.immunityinc.com" target="_blank">Dailydave@lists.immunityinc.com</a><br>
<a href="https://lists.immunityinc.com/mailman/listinfo/dailydave" target="_blank">https://lists.immunityinc.com/mailman/listinfo/dailydave</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>

</blockquote></div></div></div>