|
|
|||
|
|
|
|||
|
Folks,
To connect this to the discussion of required information for CVE entry submissions, if we were to consider a typical service vulnerability, could we describe it in the minimal CVE entry information?
CVEID PRODUCT VERSION PROBLEM TYPE PUBLICATION DATE (of the vulnerability information becoming public; or a timeline of specific events related to the vulnerability being made public) ASSIGNING CNA (or chain of assigning CNAs if there is a Sub-CNA under a Root doing the assignment) IMPACT
CVEID - Yes. PRODUCT - Which product would this be? The service? The affected component? We will need to specify this in the Rules. VERSION - If a service doesn't follow a public versioning scheme, would using the date-based method (that Kurt had mentioned) work? Should there be another scheme? PROBLEM TYPE - We haven't adopted any particular scheme for the data to be included here, so there is no current problem. Whatever scheme that may be chosen or developed in the future would have to include language that could be applied to both software and service vulnerabilities. For example, I believe CWE would still work as well as it works now for software weaknesses. ASSIGNING CNA - Yes. IMPACT - Yes.
So, no problems there, but we may need a little refinement of terminology. That is straightforward.
For a CNA assigning CVE IDs for their own products, they should have enough information to determine the existence of unique vulnerabilities and the number that should be assigned. For a CNA like MITRE or a vulnerability researcher, who often doesn't have complete information, many assumptions would have to be made during counting.
Let's say MITRE receives a report from a vulnerability researcher that there is a vulnerability in cloud service's provisioning system. The researcher can demonstrate that some kind of security policy can be circumvented. But the guts of that provisioning system are not visible to the researcher or MITRE. There has been no response from the cloud vendor after attempts at contacting them.
So, we follow the counting rules. For CNT1, we cannot tell if it is independently fixable (CNT1). We can determine CNT2.1, vendor acknowledgement. In this case, we have none, so we move on to CNT2.2A and CNT2.2B. We perceive a security-model-based vulnerability, CNT2.2B, so we move on to CNT3.
For CNT3 (which asks if there are shared codebases, libraries, or protocols), we do not know, so we assign a CVE ID for each product that may be affected. We then move on to Inclusion.
Stepping through the Inclusion rules (and assuming they are amended to allow for services in INC3), when we hit INC5 we get the "not sure" result as to whether or not the vulnerability has been assigned a CVE ID yet. Therefore, we assign a CVE ID to it.
Having done this, we can successfully navigate the Counting Rules with the minimal information given by the researcher. There is a danger that because we have such limited info, though, we may have miscounted. We cannot know for sure until the vendor publishes more information about the issue, and we can then update, split, merge, or reject the assignment.
This is all well and good, but let's fast forward a month. Another researcher contacts us with a very similar issue. Over the last month, the vendor's service has changed appearance, but the vendor offers no indicating that the underlying code has been changed, so we can't say it is a different version or not. Should we assign a new CVE ID, using date in lieu of service version? What if another researcher shows up a week later with something that is very similar to the previous two issues, but, again, we have no hard evidence that there has been a code change in the service?
Right now, without additional information, MITRE would treat all these as the same CVE ID. We may update the CVE entry with the latest date it was reported (since we have no versioning).
Ideally, the vendor will wake up at some point and start coordinating with its customers and researchers. But if they do not, the likelihood of creating many duplicates is higher than it currently is since we have more variables that are hidden from the public's view. Is that risk acceptable to the Board?
If not, should we limit CVE assignment for services only to vendor CNAs who are assigning to their own services? Is that "have/have not" structure manageable, since it creates inconsistencies on how CVE IDs are assigned and for what?
In this case, MITRE could say, "we will not assign to services, but anyone who wishes to be a CNA for services (or individual services) can under the Rules". Is that acceptable?
Thoughts?
Thanks.
-Dan
From:
<owner-cve-editorial-board-list@lists.mitre.org> on behalf of Kurt Seifried <kseifried@redhat.com>
On Wed, Sep 6, 2017 at 7:24 AM, Andy Balinsky (balinsky) < balinsky@cisco.com > wrote:
API's can and should do versioning (link to docs example, a lot of other products also do this):
And at a minimum you have dates, e.g. a vendor can say "it was vulnerable from Date X until Date Y, so any use/transactions/whatever done in that period should be redone/considered possibly exposed, whatever."
But really, people need to version APIs. It's basic sanity.
--
|
