CERTCC / VINCE

VINCE is the Vulnerability Information and Coordination Environment developed and used by the CERT Coordination Center to improve coordinated vulnerability disclosure. VINCE is a Python-based web platform.

Home Page:https://kb.cert.org/vince/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CSAF schema changes requires updates to VINCE API examples.

sei-vsarvepalli opened this issue · comments

Looks like CSAF schema is ever-evolving and changing. The new schema has dropped the previous fields such as "text" and made the "category field compulsory in many locations. The link to the latest schema is below

https://github.com/oasis-tcs/csaf/blob/d3fb9c4108faa4799aab61dce2b74fca5381623b/csaf_2.0/json_schema/csaf_json_schema.json

Required update will be managed and merged once completed by @sei-vsarvepalli

Hope to also support a Javascript version of the converter that can readily convert VINCE and CERT KB API's to CSAF format.

Please be aware that the CSAF schema has changed from the one you linked. The current one is available at csaf_json_schema.json.

More feedback from @tschmidtb51 on the example vulnerability advisory provided for VU#608209

  1. Acknowledgement: It points currently only to the CERT/CC advisory (not to
    any specific section). It would be nice, to actually have the names,
    organizations and summary in there. At least, I would expect to point directly
    to that section (e.g. with HTML anchor...)

I just had a look at it and it doesn't seem to be resolved. Can you please double check?

  1. Document notes:
    a) Element 0 (summary) should not be in the advisory, I guess.

The spelling of NicheStack changes throughout the summary. Other than that - fully resolved.

b) Element 1 (faq): IMHO this should be category `other` as it doesn't

list the FAQ directly but points to the Vulnerability disclosure policy.
Personally, I would add that as a document reference.

Resolved. :-)

  1. Document references: As that reference points to the same document
    (but just in a different format, I think it should have the category self).

Not resolved.

  1. Document tracking:
    a) Current and initial release date is still 2021-07-28. Shouldn't it be
    2021-08-04.

Current and initial release dates do not match. (There is only one version so they should match.) If you want to tell the date when the vulnerability was released: Please use /vulnerabilities[]/release_date for that. The fields in /document/tracking are only for transporting metadata about that CSAF document.

b) ID: Shouldn't that be VU#608209? If not, why is the VU# on the

website advisory always up front?

Resolved. :-)

  1. Vulnerabilities:
    a) title: This looks more like the vulnerability description to me. In the
    case of VU#257161 it looks like the first sentence should be the title and the
    second one a vulnerability note with category summary.

Not resolved.

b) CWE: is listed in the case of VU#257161 also in the title but not as

the dedicated field. Don't get me wrong here. It is perfectly fine to have that
in the title, but to do statistics it would be much better, if the cwe field is
filled ;-)

Not resolved.

c) CVSS values should be listed as scores

Not resolved.

d) product_status: It should be stated that the product is affected

and which version is fixed

Partially resolved: Affected product is listed. Patched products are not listed.

  1. Product_tree
    a) Product version: That should be the product name.

Resolved. :-)

b) product_id: That should be the product version I guess...

Resolved. :-)

c) (full product) name: Should more or less include the branches

above (name from product_name + product_version)

Resolved. :-)

Additional comments / feedback:
7. If you want to convey the internal numbers of the reports (e.g. FSCT-2020-0055) you can do so by putting that into the /vulnerabilities[]/id object:

"id": {
"system_name": "Forescout Report",
"text": " FSCT-2020-0055"
}

Thanks again for supporting CSAF. I hope this is valuable to you.

If you have any question do not hesitate to contact me.

Hello @tschmidtb51

Here is where we are at present

  1. Acknowledgements:
    I have internal VINCE production ticket that should provide anchors so we can take the person to the right section. This should be resolved soon.

  2. Document/notes[]
    This array should be fixed. May be you are seeing an older copy? I don't have the "faq" category anymore.
    "notes": [
    {
    "category": "summary",
    "text": "HCC's network stack InterNiche stack, also known as NicheLite, versions 4.3 and earlier for embedded systems are affected by multiple vulnerabilities. This set of vulnerabilities was researched and reported by Forescout and Vdoo, who calls them by nickname INFRA:HALT.\r\n\r\nNicheStack can be licensed and integrated in various ways, including compiled from source, licensed for modification and reuse and finally as a dynamic or static linked library. Nichestack is typically used in embedded devices due to its low footprint. These recent vulnerabilities stem from common memory management issues and a lack of proper input validation seen in such lightweight networking stacks and operating systems. The impact of these vulnerabilities will vary depending on the device environment and the specific implementation of Nichestack by HCC's downstream customers and potentially by other supply chain stakeholders involved in adopting NicheStack software.",
    "title": "Summary"
    },
    {
    "category": "legal_disclaimer",
    "text": "THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK.",
    "title": "Legal Disclaimer"
    }
    ]

  3. Document/references[1] should have category "self"
    Yeh - currently I didn't have any category for this field. As I saw in the JSON, the "summary" and "url" fields are the only ones required. I will add "category" as "self" no problem. This to be fixed in the next PR.

  4. (a) Document/tracking/ (current and initial release date)
    This should be fixed in the next PR. All dates are for the document as a "metadata" and not for the vulnerability.

  5. Vulnerabilities (title to move to notes[0] with category "summary"
    For now, we don't have a shorter statement for each vulnerability. So the "title" will basically be the first sentence from CVE full description in our database.

I think the CVSS is fixed in the production. The "Sample" CSAF document was old, I will replace it soon.
The CWE data is not available via API at this time as a distinct field. so we will work on it after fixing the API.

On your recommendations (7) is also currently not available a distinct field in our API output. So we will have to wait for the API fix first.

Thanks
Vijay

Hello @sei-vsarvepalli,

please find my comments inline.

  1. Acknowledgements:
    I have internal VINCE production ticket that should provide anchors so we can take the person to the right section. This should be resolved soon.

Sounds great. Please also consider to change the VINCE API to directly support the fields from CSAF as this will help companies to generate their own advisories from the information present in VINCE. IMHO most of them don't want to link to your advisory just for the acknowledgments...

  1. Document/notes[]
    This array should be fixed. May be you are seeing an older copy? I don't have the "faq" category anymore.
        "notes": [
          {
            "category": "summary",
            "text": "HCC's network stack InterNiche stack, also known as NicheLite, versions 4.3  and earlier for embedded systems are affected by multiple vulnerabilities. This set of vulnerabilities was researched and reported by Forescout and Vdoo, who calls them by nickname INFRA:HALT.\r\n\r\nNicheStack can be licensed and integrated in various ways, including compiled from source, licensed for modification and reuse and finally as a dynamic or static linked library.  Nichestack is typically used in embedded devices due to its low footprint. These recent  vulnerabilities stem from common memory management issues and a lack of proper input validation seen in such lightweight networking stacks and operating systems. The impact of these vulnerabilities will vary depending on the device environment and the specific implementation of Nichestack by HCC's downstream customers and potentially by other supply chain stakeholders involved in adopting NicheStack software.",
            "title": "Summary"
          },
          {
            "category": "legal_disclaimer",
            "text": "THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK.",
            "title": "Legal Disclaimer"
          }
        ]
    

Correct. That was fixed. I marked point of the "faq" with:

Resolved. :-)

However, I mentioned that "NicheStack" is sometimes called "NicheStack" and sometimes "Nichestack"...

The spelling of NicheStack changes throughout the summary. Other than that - fully resolved.

But you are right: this is complain about first world problems....

  1. Document/references[1] should have category "self"
    Yeh - currently I didn't have any category for this field. As I saw in the JSON, the "summary" and "url" fields are the only ones required. I will add "category" as "self" no problem. This to be fixed in the next PR.

Perfect.

  1. (a) Document/tracking/ (current and initial release date)
    This should be fixed in the next PR. All dates are for the document as a "metadata" and not for the vulnerability.

Super.

5. Vulnerabilities (title to move to notes[0] with category "summary"
   For now, we don't have a shorter statement for each vulnerability. So the "title" will basically be the first sentence from CVE full description in our database.

I see two potential solutions:

  1. Replace the /vulnerabilities[]/title with an item in /vulnerabilities[]/notes[] with category "summary" as the title is not a required field. This perfectly matches the current use (and is IMHO more reasonable as it was extracted from a full description). You can also consider to put the complete full description from your database in there...
  2. Same as 1 but add the /vulnerabilities[]/title again as the first 50 characters...
  3. Now here is a 3rd one: Change the API to provide titles for vulnerabilities - but I guess that takes more time...

I think the CVSS is fixed in the production. The "Sample" CSAF document was old, I will replace it soon.
The CWE data is not available via API at this time as a distinct field. so we will work on it after fixing the API.

👍

On your recommendations (7) is also currently not available a distinct field in our API output. So we will have to wait for the API fix first.

👍

Thanks for keeping us updated on the development and changes. And: Feel free to request me for a review anytime ;-)