Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change INC3 to allow for coverage of services #18

Open
EvansJonathan opened this issue Jul 25, 2017 · 4 comments
Open

Change INC3 to allow for coverage of services #18

EvansJonathan opened this issue Jul 25, 2017 · 4 comments

Comments

@EvansJonathan
Copy link
Contributor

GOAL: Assign CVE IDs to all vulnerabilities
CHANGE: Allow CVE IDs to be assigned to service
OUTCOME: Increase usage of CVE IDs, less confusion in the community
WORDING: Is it only in an online service (software-as-a-service), on a specific web site, or only offered through hosting solutions, where complete remediation of the vulnerability is under the full control of the vendor, and does not require any action from anyone else?

@kurtseifried
Copy link

I've pushed for this, the economic incentives are not present at this time. I would suggest that the service industry still needs time to catch up, much like software vendors did with respect to CVE. In other words "can we put a pin in it?"

@balinsky
Copy link

balinsky commented Sep 5, 2017

I believe that CNAs should be able to assign a CVE for a vulnerability in a service, even if the service resides on systems under the control of the vendor. The main reasons are for the benefit of customers of the service during the time it was affected.
Even if a customer cannot take any action to patch the system, the disclosure of the vulnerability affects them in 2 ways:

  1. They can take remediation steps to clean up the data (e.g. locking accounts whose data was compromised, issuing new credit card numbers if they were compromised, informing downstream customers of the breach, etc.)
  2. They can take an action of switching vendors if the disclosure leads them to lose faith in the vendor.

The above cases argue for disclosure of vulnerabilities in services. I would argue that whenever you have a disclosure in such a case, the community benefits from having a CVE attached to it. This is for the same reasons that issuing a CVE for any other vulnerability is beneficial. It allows researchers or security practitioners to refer to a common issue. What if there are 3 similar vulnerabilities in a given service during a year? Must a researcher refer to them by disclosure date or by some company advisory disclosure identifier or URL? These things may change over time. A CVE is a fixed, permanent reference point. All vulnerabilities that are significant and enter the realm of public discussion will benefit from having a common identifier attached to them.

@zmanion
Copy link

zmanion commented Sep 20, 2017

While harder to track than product vulnerabilities, it should be possible to assign CVE IDs to service vulnerabilities. This doesn't mean that we immediately expect CNAs to spring up and cover all/lots of service vulnerabilities, but it should be possible.

@dadinolfi
Copy link
Contributor

The Board discussed this further during their 9/20 meeting. They determined that we need to do more research on the implications of this change. This will not be included in the current revision cycle, but it may be included in a future revision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants