Global Security Database

 View Only
  • 1.  GSD Numbering Format

    Posted Jan 31, 2022 10:13:00 AM
    Hi Everyone

    I have been looking for a document that outlines the rationale for the GSD numbering. 

    From the demo, I see the GSD number format appears to be GSD-yyyy-xxxxx which is similar to the CVE numbering. 

    If there isn't a document that outlines the rationale, is someone able to tell me why the year is embedded in the number? I recognize that it is similar to the CVE numbering but other than that, is there a reason for embedding the year rather than simply incrementing the number?

    Thanks!

    Bill


    ------------------------------
    Bill Hughes
    Weehooey Inc.
    ------------------------------


  • 2.  RE: GSD Numbering Format

    Posted Jan 31, 2022 11:03:00 AM
    In the past the CVE rational was the year was embedded so you knew when the vuln was from. That made sense in 1999, less now, but it is still a helpful aspect of "at a glance" you can see scan results for example and see how out of date you are (e.g. if you see GSD's from more than a year ago...). 

    Another advantage of the YEAR as a number is that we can make changes to the ID part itself, e.g. right now we use an integer but maybe some year we switch to hex/sha512/etc. at some point.

    The other aspect is that all the tooling expects a year and a number, so changing that breaks all the tooling. 

    And there's no significant downside to putting the YEAR in, one note: CVE uses yEAR as "when this was known to be a vulnerability" which can be problematic (e.g. what if you find an old posting? do you bother reissuing it?), the DWF simply uses the YEAR as when the id was assigned, very simple.


    ------------------------------
    Kurt Seifried
    Chief Blockchain Officer and Director of Special Projects
    Cloud Security Alliance
    [email protected]
    ------------------------------



  • 3.  RE: GSD Numbering Format

    Posted Feb 01, 2022 07:29:00 AM
    Edited by Bill Hughes Feb 01, 2022 07:29:03 AM
    Hey Kurt

    Thank you for your explanation. 

    My impression is that the GSD is trying to fix the broken parts of the CVE system. Making the CVE ID a string with random information embedded is broken and requires extra handling in code and administration. Yes, granted most developers can handle it but why add unnecessary complexity?

    If embedding the year is helpful, perhaps other information can be helpfully embedded? Why just the year? What about the month? The submitter? You get my point. 

    The only real requirement of an identification number is to uniquely identify the instance of what it is identifying. The helpful parts come from the other fields. 

    Where would I submit a proposal on the GSD ID? My proposal would be something like:
    • GSD ID number is an integer. 
    • When representing the GSD ID number in a data object, you shall use a key-value pair where the key is "gsd-id" and the value is an integer. 
    • When representing the GSD ID in a database, the field name should be gsd-id and the data type is integer.
    • When writing a GSD ID in text, it shall be written as GSD-xxxxxx without zero padding. 
    • When displaying the GSD ID in a view, it shall be clearly labelled as "GSD ID" or dynamically displayed like text (prepend GSD-)
    A couple of modifications that may be useful to make it more human friendly:
    • Represent it in hex. This would make it shorter.
    • Allow for an additional separator character when displaying it to humans (like a phone number or money) but as data, it would remain an integer. This would need to be part of the standard so that it is consistent. 
    It is still early enough that a change could be made. 

    Cheers


    ------------------------------
    Bill Hughes
    Weehooey Inc.
    ------------------------------



  • 4.  RE: GSD Numbering Format

    Posted 4 minutes ago
    So we tried fixing CVE, but it turns out that probably isn't possible, this old blog entry still holds true:

    https://cloudsecurityalliance.org/blog/2022/02/22/why-we-created-the-global-security-database/

    ------------------------------
    Kurt Seifried
    Chief Blockchain Officer and Director of Special Projects
    Cloud Security Alliance
    [email protected]
    ------------------------------