Why doesn't HDF include an id field?
brettforbes opened this issue · comments
Its hard to understand why you want us to adopt HDF, when it doesn't have an id field. We currently support all of the OASIS protocols, and Mitre ATT&CK. Why is your proposal different to all others?
Every single OASIS object has an id field, all in the same format, yet this one doesn't, why? What is the benefit of not having an id, as opposed to every other OASIS protocol where they adopt a standard id format?
Why this decision? How is one to exchange data with others? Is there a rationale for avoiding an id for this specific use case?? What possible benefit is there for not having an id?
There seems to be some serious limitations in the thought on this proposal, or perhaps there is a good reason as to not having an id field that i am not aware of, and this justifies making it different to every other OASIS protocol. I look forward to understanding why you dont want to be compatible with other OASIS protocols, and see the need to do something different
It does have an ID field, multiple ones in fact, each control object has an ID. Each Profile has an array index ID and a title and a SHA sum which acts as a unique candidate key for that index - aka ID - for that profile in the set.
Excuse my ignorance, but i am examining thins documentation page here https://saf.mitre.org/#/normalize
But what you are saying is there is no id for the record, instead and strangely there are id's for array objects inside the profile objects, so three levels deep, or i have to infer the SHA256 as an index at two levels deep, yet there is no overall index.
This is a really questiomable data design as it makes the retrieval and even specification of any unique record far more complex than it needs to be. So this seems poorly thought through by Heimdall and pretty unsatisfactory overall.
In short, if i get your gist. The reason there is no unique id at the top level is that no one wanted terse queries to retrieve records, or thought that might be useful, and instead we need to infer uniqueness from the contents???
What if i make two deployments of the same code, with two tests? In this case the SHA-256 is the same, and your key is broken. This idea of using contents to infer uniqueness seems hard and fragile, Hmm, we will have to make submissions to OASIS on this as it seems weak and not as robust as it should be from a data modelling perspective.
This is no criticism of Mitre, and instead is a criticism of the HDF as a concept, as it appears to have questionable data modelling credentials. I should be able to pull the entire record by saying
match $hdf is a HDF, has hdf-id "HDF---b76ed159-6b5c-4d89-8286-ccf339d38ad0";
All other OASIS protocols match this type, simply because it gives you a very easy mechanism of storing and retrieving objects, as well as the ability to simply match objects. Surely I would want to store my HDF close to my SBOM (e.g. CycloneDX) and my VEX since CSAFv2 is also critical for DevSecOps. Or will your stuff not be compatible with the other OASIS protocols?
I also note that the software scanners you support produce vulnerabilities. Vulnerabilities are described using the stix language, which is yet another OASIS language that supports an ID as shown above.
So it seems that the summary of the position is that one can have a single database to contain all of the OASIS protocols, as well as MITRE ATT&CK and DEF3ND. But one needs a completely separate database to store the MITRE SAF stuff in, and it cannot be linked to anything else. In short, it seems to be an island., or am i missing something fundamental?
Perhaps it is really all me misunderstanding how MITRE SAF works, or perhaps I can make a request to OASIS to get an additional ID field added, so we can arrange compatibility with the other protocols, or perhaps there is a third option which i cannot see.
What is the best way to arrange compatibility between this and other OASIS protocols?
Hi @brettforbes. This hasn't been an issue for us in our personal experience or even in multi-format storage solutions that we've helped our users with, but that doesn't mean your usecase isn't valid. If you check out Heimdall, you'll see that most of the focus has been on the contents and not the container itself (i.e. the HDF schema). After we set up the OASIS repository to host the schema and related documentation, perhaps we can talk/have you propose an RFC about a top level id field.
@brettforbes https://github.com/mitre/saf/wiki/HDF-Mapper-and-Converter-Creation-Guide-(for-SAF-CLI-&-Heimdall2)#fullschema may also be useful for helping bridge the gap as well. Looking forward to working with you and finding the gaps and improvements if needed.