Slashdot Mirror
Rethinking Security Advisory Severities
An anonymous reader writes: The recent OpenSSL vulnerability got the internet all hyped up for a security issue that, in the end, turned out to have a very limited impact. This is good news of course, we don't need another Heartbleed. But it raises the question: should security advisories be more clear on the impact and possible ramifications of such a vulnerability, to avoid unnecessary panic? Developer Mattias Geniar says, "The Heartbleed vulnerability got the same severity as the one from last night. Heartbleed was a disaster, CVE-2015-1793 will probably go by unnoticed. ... Why? Because CVE-2015-1793, no matter how dangerous it was in theory, concerned code that only a very small portion of the OpenSSL users were using. But pretty much every major technology site jumped on the OpenSSL advisory. ... The OpenSSL team is in a particularly tricky situation, though. On the one hand, their advisories are meant to warn people without giving away the real vulnerability. It's a warning sign, so everyone can keep resources at hand for quick patching, should it be needed. At the same time, they need to warn their users of the actual severity.
I don't disagree but I think the Heartbleed bug caused a lot of trauma so now people jump whenever there is a vulnerability in OpenSSL,,
Especially when you're talking about FOSS, nobody really knows who's running what code out there.
It's going to be difficult for a library developer to know precisely how many people are using a particular feature, even if they have a general sense of feature or version popularity. Moreover, to the relatively few people affected by this, this absolutely WAS a critical bug. Unless you are clear and candid about the seriousness of the bug, those people that need to patch may not hear about it. It's probably best for them not to make wild guesses about who they think are affected. Stick to the facts, and let others determine the ramifications.
I don't really care about "unnecessary panic". Better more awareness of issues than less. The real danger, of course, is that if you overblow the *practical* danger, then people may stop paying attention. It's likely the media jumped on this only because of the recent memory of Heartbleed. Once that gets old, they'll stop with the insta-panic over each new security issue, and we'll be back to normal (which is probably *not enough* panic over serious issues).
Irony: Agile development has too much intertia to be abandoned now.
The sheer number of screwups and bad code in that library means the real advisory should be Avoid OpenSSL. Use LibreSSL instead. Its team knows how to write robust code and stripped out much of the worst stuff.
By trying to not say too much, the advisories are inherently vague and therefore can be interpreted as insignificant or a dire emergency depending on the day.
That's not useful to anyone.
Because the NSA and GCHQ have effectively eliminated all network security, thanks to their backdoors in things like Cisco devices, it should be automatically assumed that all the bad guys capable of exploiting the issue already have all the information they need and the bad guys not capable of exploiting the issue aren't an issue whether informed or not.
Advisories should therefore declare everything. Absolutely everything. And it should be made clear in those advisories that this is being done because the risks created by the backdoors exceed the risks created by the additional information.
The added information will aid in debugging, clearing up the issue faster and validating that no regressions have taken place.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
watch out. something could happen. any day now.
Oh wait. It's called the CVSS. Only your system admins and security folks will know how vulnerabilities apply to your organization. Temporal and environmental factors and only be assessed by people in the know. Windows shops obviously don't care about Linux vulnerabilities and vice versa. The base ratings are strictly focused on the vulnerability. Other factors you need to determine yourself... And there's already a system for that.
From what I read of the vulnerability, it was severe enough to merit the severity level given to it. If you were affected by it. That's the catch. This is the canonical "severe but unlikely" scenario, somewhat like one where cars are known to randomly explode killing everyone within a 10-mile radius but only the Ford Focus will do this and only if it's got the metallic purple paint job that was a custom order and there were only a couple dozen sold. You can't rate it low severity because losing that big a chunk of a major city is hardly "low severity", but you don't want to have everybody fretting about the safety of their cars when it's only a couple dozen people involved. There isn't a good way to describe this kind of scenario except by giving details, even if those details will let black-hats know which cars to steal to use as rolling bombs. And then there's the usefulness of the warning. IMO if the notification doesn't contain either instructions on how to mitigate the vulnerability or enough information that I can work out what the vulnerability is and how to mitigate against it, the notification's of absolutely no use to me. If you can't/won't give me enough information for me to protect my systems then I'd rather you didn't bother with a vulnerability notification, just fix the problem and flag the next release with "important security fix, details are in the changelog". But I'd prefer that you just provide the information.
Half the problem is inconsistent use of the scoring system. OpenSSL uses CVSS to measure the impact to the SSL channel that is compromised with no attention to the additional damage it directly enables. Some other vendors follow this approach. Others (like myself) include everything you can now access through exploiting the measured vuln as part of the impact of the vuln.
This means that (a) different places use the same scores to mean different things and (b) it is possible to minimize the score while not demonstrating the true impact.
CVSSv2 is a perfectly usable metric by which to classify risk of security incidents.
From what I have seen, Mitre and NIST often show inaccurate CVSS scores on the CVE pages. In order for the metric to be truly useful, every organization has to localize measurement to their environment and each vendor needs to measure impact against their use or non-use of the underlying code. At the end of the day, it's all about risk measurement, but with those steps you end up with a reasonably accurate assessment.
I speak as someone who monitors RSS feeds of CVEs and deals with both responses to and creation of CVE statements. There is nothing wrong with the current system that wider spread adoption and education cannot fix. Part of the problem is the media hype surrounding the bugs. If every little issue wouldn't get a cute name -- Shellshock, Logjam, POODLE -- the reactions might be a little less kneejerk.
100 REM PISS OFF CODE FASCISTS 200 GOTO 100
You can check by running sslscan.
If this issue was really what they said it was, why are people still running it?
The PCI folks said the end of June was the cutoff - but was it?
Whatever
Meh
Bad
Very Bad
Very, Very Bad
OMG!
ZOMG!!
OMFG!!!
You mean, can we somehow keep our users from needing to RTFM? There is an easy answer for stupidity, or laziness. You make bad decisions. The severity is the severity; it is up to the user to know if they are running the code or not. If they can't be bothered to know that, then they should not be in charge of security, since they'll be making shitty decisions anyway.
I like Einstein's quote: Make everything as simple as possible, and no simpler. We miss that last part, usually.
I art more snarky, and terse than thou. I art Slashdot!
then you can definitely realized it. Almost all famous celebrities are aiming to own and wear different Gucci accessories, clothing, perfume and cologne and other products. Gucci world offices and headquarters are in Florence, Paris, London, and New York. To date, the brand is very popular in fashion capitals of the world like New York, Paris, and London timberland Homme .Peter Rock generally writes on perfumes, beauty product, and beauty lotion etc. He has written many articles on beauty products. Peter Rock also writes this article. Visit the site; find out various remarkable Gucci perfume.Royalty Free Stock Photofrom © Dreamstime.com Gucci shoes are some of the most widely imitated shoes on the market. Before buying a pair of Gucci shoes online, make sure that you are not accidentally investing in a fake. Browse the guidelines below for tips on how to avoid a cheap imitation of the Gucci brand. What to look for on the inside of a genuine Gucci shoe: Each authentic Gucci shoe is given an eight digit serial number that is stamped on the shoe's leather lining. All serial numbers are exactly eight digits long, so count before you buy! This serial number should be discreet; it is usually placed on the inside of the shoe next to the shoe size. The "Gucci" brand should be stamped inside the shoe on the heel. Next to the brand name should be a stamp saying "Made in Italy". Both of these stamps should be easily visible.
This latest episode was announced as if it had serious and broad impact. It did not, but that didn't help those of us who, on less than two days notice, moved things around to prepare for another round of mitigation of a "severe" security issue. Yes, we're all glad it's not as bad as it might have been, but the point is that somebody was aware of that when the announcements went out. They should have been more forthcoming.
The recent OpenSSL vulnerability got the internet all hyped up for a security issue that, in the end, turned out to have a very limited impact.
Oh right, just like the hype around Y2K turned out to be nothing right? The point is that some big problems would have resulted if the problem hadn't been hyped and fixed beforehand or in the early hours of the problem being exposed. Whenever I hear someone say "That Y2K thing turned out to be nothing" I just shake my head. Why is this concept of prevention so hard for the general public to understand?
I think the level of severity is something that should be determined by the individual or organization.
Disclosing severity gives some idea of what we're up against. But the actual damage is dependent on environment.
=