再保险:CVE托管服务

在星期一,2017年2月27日,艺术·马尼恩写道::2017-02-24下午,耶利哥写道:::>没有,味道中,使用“CVE”作为ID计划的一部分。有:>完全没有逻辑的或有益的理由这样做。::我曾以为不会改变的计划,但没有给它很多:想。不确定我看到一个逻辑或创建一个有益的原因:单独的“服务”计划,但是我并不反对。说实话,不知道你今天会说。也就是说……:> - CVE支持十年两个前缀方案(CVE)。::有两个方案的原因,世界改变,CVE进化而来的。:我记得这是相当繁琐(尽管这可能是:有价值的早期的CVE)。* *是一个原因…… "the world changed"... "CVE evolved" How can you say all of that, and not see the benefit of using a different designation. This is a text-book list of reasons to change the prefix. : What does CAN/CVE mean in this discussion? : : > - Many orgs will not want to track online services, and mixing them will : > make that very painful for 'coverage [metrics|percentage]' etc. : > - Some orgs may be more interested in cloud/service offering tracking : > (e.g. companies that exist for cloudy services themselves) : : Seems reasonable. Is there another way to flag "service" vulns? Uh... yeah. Virtually no one does it now. And if you find someone that does it, and is actively updating it, they do NOT do it in the context of CVE, VulnDB, XF, BID, CERT, or any other traditional vulnerability database. I say this as someone who helped try to start a 501c3 version to track site-specific vulns (originally in the context of outages, then in vulns). Either we were ahead of the curve, or no one really cares. In 2017? I know a few care, I understand why we're having this conversation. We figured tracking that many years ago was a thing, before it actually was. So... as someone way ahead of the curve? Track it, all day long. Just don't try to do it in the same context of CVE. : > - For the countless vuln tourists (both individual and companies) that do : > yearly stats entirely based on CVE and not understanding CVE at all, : > this will forever make ALL stats they generate entirely worthless. I : > mean, they are already worthless, but this will make it more so. : : Counting is broken, for many reasons, which you know better than most. I do. It might be the single thing that I would EVER accept someone else calling me an 'expert' on. : That's as much a function of the nature of vulnerabilities as it is the : effort anybody puts in to counting. : : Identification, identification, identification. True, and also 'cute'. Not many of us out there that track vulns to a specific degree. A large part of my disconnect from the board over the years is that most "do CVE" for their own purposes. I have called that out too in the past. To quote your line, which *absolutely* speaks to the point: : Identification, identification, identification. But.. that isn't predicated upon combining two radically different concepts, into a unified ID scheme. And no one, at all, on this board can argue they are not radically different concepts (in our world). 17 years of CVE, no site-specific other than when ignorant resaerchers requested an ID, got an assignment, and later disclosed a site-specific issue. Oh, yeah, sorry... not counting IBM, a CNA, who did it once or twice =) (love you Scott!) 17 years of *firm* rules... well, mostly firm until the CVE board itself, who didn't really read the rules in some cases, suggested such site-specific assignments should be a thing... and I had to call out MITRE on that policy, who specifically said "no site-specific"... and then a few months later said "well... maybe site-specific"... My point is, let's just be clear what was hardcoded rules for approaching two decades... and what was introduced in the last 12 months (not for the first time)... and now there is a growing discussion of changing the scope of CVE radically... (and hey, if this is evolution, fine!), but no one immediately speaking up to support the stupidly logical evolution of "make it a new C*E project". Seriously. CVE, CWE, CME, CPE, and several other C*E that didn't make it. That is the MITRE way. While many joke about it, including me, it is actually the logical, efficient, and practical way to expand CVE scope. Anyone who suggests that site-specific vulns should be wrapped into CVE rather than being split into a new C*E project? This is where I draw the line. Feel free to step over it. : > - Did I mention there is no logical reason to mix them under a unified CVE : > identifier? =) : : You did, but I throw the tautology flag :) Yeah, the tautology (great word!), was by design, to help ensure that no one made a quick emotional vote, withouth consider the impact. .b