再保险:CVE计算文件的草稿

库尔特,多谢反馈……我非常感谢它。仅供参考……我没有考虑帕斯卡反馈在下面的评论,但我添加帕斯卡脆弱性的定义,我觉得效果很好。谢谢帕斯卡!>我们可以添加“一般要求”吗?我添加了一些文本的定义。看一看,让我知道如果这对你有用。>能装置(供应商确认)被扩大到包括实际>验证通过概念证明/再生器为例,或通过源代码>考试吗?我会关心在包含阶段把严格的验证要求。 For vendor CNAs, I think they will most likely do some or all of this, and maybe we can insert this language here that mentions it. However, there may also be other CNAs reading this decision who are not the vendor or maintainer of the product/code and assembling this data or getting it from the vendor could take time if it happens at all. My feeling is that the inclusion steps should emphasize speed in assigning CVE IDs as opposed to getting things perfect up front. If a mistake is made, it can be cleaned up after the fact. Thoughts? > INC3.1 "demonstrated" does this mean we need a reproducer? Similar to the above, for a vendor CNA following this it is probably not much of an issue. For a CNA who is not the vendor or maintainer, such as yourself, this becomes more important obviously. I think you have said yourself that you get lots of garbage already. In my mind, "demonstrated" means can the requester properly describe the vulnerability and explain what it's impact is. I think if we force the requester to provide a PoC we may be asking for too much at this stage. As the bolded text states, this one is about trusting the researcher in their claim to a certain extent. > INC4: can we better define public/private? E.g. what if a medical > device maker plans to use a CVE for an issue that they will then > inform ever user of directly? Ditto for aerospace/SCADA/etc. Are you saying that we should soften language now to start including room for CVEs issues that will only be released to a limited group of users? I know we have had these discussions in the recent past, but my understanding was that we would wait to make this kind of change until CVE actually brought on some of these domains where this issue will come up. > INC5: "CVE IDs are assigned to products that are customer-controlled > or customer-installable." what about on premises solutions that are > locked down? I know many medical devices, high end manufacturing, etc > you buy it, but you don't touch it, the company tech services it. > Ditto for other regulated items like elevators (contractually most > elevator maintenance involves a "if anyone but us touches it, your > warranty is totally void"). This is a really great point! This is another area that I haven't really put much thought into and I don't think anyone else on the board has brought up in the recent past. Outside of the "sort of" similar idea of SaaS (and possibly other xaaS), I imagine there could be IT products (e.g., appliances and such) produced now or in the future that could fall into this category. Similar to the above comments though, should we account for this in the current rules, or should we wait until presented with this problem such as when we bring on the medical devices domain? > CNT4: I'd like to better define the embedded code situation, e.g. > libxml/gzip situations (bits of those are everywhere!). One thing that I noticed is that the decision language did not direct the CNA to defer the report to the appropriate CNA in the case of a shared codebase that doesn't apply to the receiving CNA (i.e., the CNA following the decisions based on the report). Are you looking for more process explanation in this case or maybe more examples? If you have anything specific please feel free to pass along. Chris From: Kurt Seifried [mailto: kseifried@redhat.com发送:周三,2016年8月24日,55点:棺材里,克里斯< ccoffin@mitre.org > Cc: cve-editorial-board-list < cve-editorial-board-list@lists.mitre.org >主题:Re:草稿CVE计算文件的一些反馈:上下文中的一个漏洞CVE程序,是可以利用的代码,导致负面影响保密,完整性和可用性,需要一个代码更改来减轻或地址。一些vulns内部协议和唯一的代码更改,“补丁”是完全删除代码/功能。我们可以添加“一般要求”吗?我担心软件/ API的交集vulns将越来越普遍(多个实例,和人们会开始寻找)。能装置(供应商确认)被扩大到包括实际验证通过概念证明/再生器为例,或通过源代码考试吗?INC3.1“证明”,这意味着我们需要一个扬声器?INC4:我们能更好的定义公共/私人吗?例如如果一个医疗设备制造商计划使用CVE为一个问题,然后他们会通知用户直接的?同上航空/ SCADA /等。INC5:“CVE id分配给产品customer-controlled或customer-installable。”前提方案上锁定呢? I know many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the company tech services it. Ditto for other regulated items like elevators (contractually most elevator maintenance involves a "if anyone but us touches it, your warranty is totally void"). CNT4: I'd like to better define the embedded code situation, e.g. libxml/gzip situations (bits of those are everywhere!). On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris <mailto: ccoffin@mitre.org>写道:,附件是一个新版本的CVE计数CNAs文档。我已经做了一些修改计算决策以及提供了一些澄清在某些决策基于CVE团队的反馈。克里斯:mailto: owner-cve-editorial-board-list@lists.mitre.org(mailto: mailto: owner-cve-editorial-board-list@lists.mitre.org]代表棺材,克里斯派:周一,7月25日,2016 5:03点:cve-editorial-board-list <mailto: cve-editorial-board-list@lists.mitre.org>主题:CVE计算文件的草稿,抱歉延迟,这些本该上周出去。附件是最新的标记版本的简化计算规则,以及承诺非常粗略的版本的新CVE漏洞计数CNAs文档。仍有大量的工作要做在这个新文档,但是到目前为止主要开发决策树。包括决策树是为了取代老的决策树发现https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md。目前的想法是,“独立可以解决的”概念的引入,废止的许多老数决定,但我们有兴趣听听别人的意见。同样,包含规则实际上增长了一点,但这些似乎都是相当简单的。报告类型决定是在内部讨论,对每个人都可能是新的。早期版本的文档没有良好的覆盖独立时如何计算可确定的导致没有或不确定。报告类型可以将普通的报告病例是在一种统一的方式来处理。这个想法是为了处理最常见的报告和建议为每个计算行动。我们绝对是兴趣倾听他人的想法全部计算决定,以及常见的报告和操作定义。就像我之前说的,这是一个非常早期版本我开放给任何反馈。提前谢谢! Chris Coffin The CVE Team -- -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Red Hat Product Security contact:mailto: secalert@redhat.com

附件:为CNAs_v0.5.docx CVE计数
描述:为CNAs_v0.5.docx CVE计数