search

oasis-open / cti-stix-common-objects

OASIS Cyber Threat Intelligence (CTI) TC: A repository for commonly used STIX objects in order to avoid needless duplication. https://github.com/oasis-open/cti-stix-common-objects
BSD 3-Clause "New" or "Revised" License
84 stars 37 forks source link

CVE ID and UUID #18

Open adulau opened 2 years ago

adulau commented 2 years ago

Are the CVE ID generated in a fixed way like using UUIDv5?

It seems the current script https://github.com/oasis-open/cti-stix-common-objects/blob/main/scripts/generate_common_objects.py#L123 is generating automatically the UUID which is a bit counter productive.

Especially that a CVE ID is fixed and if you know the original seed for the UUIDv5, the UUID can be looked up directly without any search.

rpiazza commented 2 years ago

@adulau - you are correct. There is some discussion about whether a Vulnerability object should be created for each CVE in the common object repository. Others have also suggested using UUIDv5, although at this point with 100K Vulnerability objects already created I'm not sure what the best way forward is.

elemendar-syra commented 1 year ago

@rpiazza I'd also be really keen for there to be a fixed way for generating IDs (starting at some point at least, as it's easy enough to map to the historic ones) as this would make it easy to generate CVE Vulnerability objects on the fly that can then easily match up to the OASIS ones, through a duplicate-of relationship or similar so that everything can come together nicely.

As a suggestion, from a certain point could UUIDv5 with an OASIS namespace and generating the rest based on the CVE name not easily do this? Would be a lot easier than constantly pulling down form the repository (especially when trying to map to the common objects when we're running on client sites where we don't have control of firewall rules etc)

elemendar-syra commented 2 months ago

@rpiazza I'm happy to implement this concept, if I can get access to create a branch and an MR for you?

rpiazza commented 2 months ago

Related issue #77

I am completely in favor of changing the way we currently generate Vulnerability objects based on CVEs. Storing them in Github has become somewhat untenable. There are several good ideas, using UUIDv5 ids based on the CVE id, using the NVD API, etc.

Using UUIDv5 ids for SDOs is not explicitly prohibited by the STIX 2.1 spec, although using them for only SCOs was the intention.

One important thing to keep in mind is what the STIX Vulnerability object should contain. Should it have all of the information in the CVE/NVD entry - which would require an extension (this is how ATTACK attack-patterns were implemented). Or is it just a link to the NVD/CVE data (which is how it is implemented now in the Common Object Repository).

Most of all, I think before anyone implements anything the TC should provide guidance.