Global Security Database

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.
------------------------------

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
kseifried@cloudsecurityalliance.org
------------------------------

Original Message:
Sent: Jan 31, 2022 10:04:47 AM
From: Bill Hughes
Subject: GSD Numbering Format

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.
------------------------------

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.
------------------------------

Original Message:
Sent: Jan 31, 2022 11:03:12 AM
From: Kurt Seifried
Subject: GSD Numbering Format

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
kseifried@cloudsecurityalliance.org

Original Message:
Sent: Jan 31, 2022 10:04:47 AM
From: Bill Hughes
Subject: GSD Numbering Format

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.
------------------------------

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
kseifried@cloudsecurityalliance.org
------------------------------

Original Message:
Sent: Feb 01, 2022 07:28:33 AM
From: Bill Hughes
Subject: GSD Numbering Format

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.

Original Message:
Sent: Jan 31, 2022 11:03:12 AM
From: Kurt Seifried
Subject: GSD Numbering Format

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
kseifried@cloudsecurityalliance.org

Original Message:
Sent: Jan 31, 2022 10:04:47 AM
From: Bill Hughes
Subject: GSD Numbering Format

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.
------------------------------

Hi Kurt,

So what now?

------------------------------
Michael Roza CPA, CISA, CIA, MBA, Exec MBA
------------------------------

Original Message:
Sent: Jul 03, 2022 02:40:03 PM
From: Kurt Seifried
Subject: GSD Numbering Format

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
kseifried@cloudsecurityalliance.org

Original Message:
Sent: Feb 01, 2022 07:28:33 AM
From: Bill Hughes
Subject: GSD Numbering Format

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.

Original Message:
Sent: Jan 31, 2022 11:03:12 AM
From: Kurt Seifried
Subject: GSD Numbering Format

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
kseifried@cloudsecurityalliance.org

Original Message:
Sent: Jan 31, 2022 10:04:47 AM
From: Bill Hughes
Subject: GSD Numbering Format

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.
------------------------------

We've been making progress: https://gsd.id/ for more info.

------------------------------
Kurt Seifried
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
kseifried@cloudsecurityalliance.org
------------------------------

Original Message:
Sent: Jul 04, 2022 02:05:12 AM
From: Michael Roza
Subject: GSD Numbering Format

Hi Kurt,

So what now?

------------------------------
Michael Roza CPA, CISA, CIA, MBA, Exec MBA

Original Message:
Sent: Jul 03, 2022 02:40:03 PM
From: Kurt Seifried
Subject: GSD Numbering Format

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
kseifried@cloudsecurityalliance.org

Original Message:
Sent: Feb 01, 2022 07:28:33 AM
From: Bill Hughes
Subject: GSD Numbering Format

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.

Original Message:
Sent: Jan 31, 2022 11:03:12 AM
From: Kurt Seifried
Subject: GSD Numbering Format

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
kseifried@cloudsecurityalliance.org

Original Message:
Sent: Jan 31, 2022 10:04:47 AM
From: Bill Hughes
Subject: GSD Numbering Format

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.
------------------------------

Original Message:
Sent: 7/6/2022 1:14:00 AM
From: Kurt Seifried
Subject: RE: GSD Numbering Format

We've been making progress: https://gsd.id/ for more info.

------------------------------
Kurt Seifried
Chief Blockchain Officer and Director of Special Projects
Cloud Security Alliance
kseifried@cloudsecurityalliance.org
------------------------------

Original Message:
Sent: Jul 04, 2022 02:05:12 AM
From: Michael Roza
Subject: GSD Numbering Format

Hi Kurt,

So what now?

------------------------------
Michael Roza CPA, CISA, CIA, MBA, Exec MBA

Original Message:
Sent: Jul 03, 2022 02:40:03 PM
From: Kurt Seifried
Subject: GSD Numbering Format

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
kseifried@cloudsecurityalliance.org

Original Message:
Sent: Feb 01, 2022 07:28:33 AM
From: Bill Hughes
Subject: GSD Numbering Format

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.

Original Message:
Sent: Jan 31, 2022 11:03:12 AM
From: Kurt Seifried
Subject: GSD Numbering Format

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
kseifried@cloudsecurityalliance.org

Original Message:
Sent: Jan 31, 2022 10:04:47 AM
From: Bill Hughes
Subject: GSD Numbering Format

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.
------------------------------