8 May 2018 – cti tc working Call Notes Proposed changes to hashing-algorithm vocab

8 May 2018 – CTI TC Working Call Notes

Proposed changes to hashing-algorithm vocab

* Allan: I don't understand why we're changing something that's not broken. What's the reason to change this? Changes proposed seem bigger than necessary.

* Ivan: thought process was to make it cleaner and easier by restricting it to the values that are actually used today

* Trey: reasoning is that, as now, it's a MUST use a value from an open vocab. We could either change that to a should or could just change the ov to an enum

* Jason: removing SHA-3 is also disturbing

* Ivan: this could always be added back in the future

* Trey: why don't we come at this from artifact encryption?

* Changes were suggested based on looking at encryption and seeing how hashing is used

* Bret: supports the changes. We can add new entries as the market adapts.

* Related to the change for external references as well

* Allan: disagrees that just because something is in a list of open vocabs means you have to implement it

* Trey: agrees w/ allan that you don't have to implement all these

* Chris Ricard

* With an open vocab you can't really guarantee people will use SHA-256 vs. sha-256 vs. sha256

* The day MD6 becomes a supported thing you have a whole bunch of people creating new properties, then when we add it to the vocab, old hashes that were in the property need to be converted

* Bret: things we're getting back in to the realm of STIX 1, where we solve problems down the road. Make the list represent what the market does and move on

* Ivan: open vocab is duplicative with the x_ approach

* John

* Could take a middle ground and tune down the vocab but not make it a closed vocab

* JMG

* You don't have to implement all the hashes in an open vocab

* We shouldn't do x_ prefixes because of IETF RFC

* JMG thinks we should keep SHA3, at least one of them

* Rich Piazza

* Nowhere in the specification do we talk about the format of the things you add to an open vocab, but it was never stated

* Trey AI: Open issue to clarify how to add values to open vocab in Part 1

* Bret: we have text for custom properties, but not for custom key in a dictionary

* Trey: can we keep this as an open vocab, pare it back to what we see and use, keep one of the SHA types. Is that rough working consensus?

* Bret: we may not have consensus on not moving from open to closed

* JMG: questions paring down the vocab if we leave as open

* Allan: suggests paring down vocab, text to ensure people will use it correctly, leave as open

Part 5 issue: return TRUE or FALSE if you're not able to evaluate a property on a pattern

* Jason: we need to return true to avoid missing things

* JMG: one of the issues with matching on custom properties is that if you depend on TRUE to be not present, and you have someone else with the same name custom property but the same type, you have a conflict

* There really needs to be an understanding of what properties are being generated and what you're comparing against

* Agree that we need to define the behavior of this. Would propose that the pattern define whether this is true or false

* In other cases we define not present as false, but if we have other problems because a property not present means more than just not implemented

* Allan: mostly agrees with JMG...not implemented is not by default true. That would be very bad...

* This is a product choice. Tools should be able to define it. Would be strongly against a MUST. We could provide an "error" or non true/false response

* Jason

* What's being suggested is inside your pattern you're required to specify how it should behave. It seems like we could do that, what would the default be? At the end of the day we need a default.

* Trey: for purposes of issuing CSD01, how about we pull this text out and create a github issue?

* ***Call for objections to push to CSD02. No objections.***

* JMG: we also have a proposal for is_property_present, which could help solve this

* Another question is what was implemented in the existing library

Github Issue 37 - Labels

* Allan: when was the core issue decided? The names don't matter, what we need to decide is whether there should be one property or two. Consensus was to separate the labels property into two separate properties? In that case I will change my vote; my primary question is how can you standardize on organizations using a machine-defined vs. user defined tag correctly. What will happen is that they end up mixing and vendors will end up having to merge them.

* Trey: In terms of machine processing, if I have a spec that gives me a list of defined tags, I can very easily whitelist those in my code and machine process those. I don't really understand why having a single property for this is a problem.

* Bret: My proposal was based on going back to our original idea of STIX 2.0 of having a separate labels and tags properties.

* John: The way things are is we have one property called labels.

* Chris: I'm not a developer, but I agree with Bret's judgment that having one property with a mix of labels and tags is a programmatic issue. Based on that, I was thinking this is a serious issue for developers and something that needs to be resolved. Personally, I think of labels and tags as being almost interchangeable, though I can live with whatever we call them.

* JMG: One thing that's not clear is that when we make the change, labels will become a closed vocab and tags will become open, is that correct?

* John: Not quite, labels will be an open vocab and tags will be a list of strings.

* JMG: If labels remains an open vocab, you'll have the exact same problem that a combined vocab has. Namely, being able to tell the difference between a machine generated tag and a user generated tag. This is an extremely hard data curation problem, and I'm not quite sure whether splitting the property into two is correct or not. If we made labels more restrictive (closed) it would make more sense to split them up.

* Bret: I would be fine making the types/labels a closed vocab. From a processing standpoint, if we have a generic bucket of terms that is an open vocab, you can pivot on it and do some processing on it. However, we've added terms related to processing and other functionality, so now you have no way to determine in code whether a label corresponds to a known classification or something random.

* Jason: To me property 2 is not a vocab at all, it's just a list of strings. The difference isn't whether it's machine readable, rather it has to do with the information source, whether it's trust group originated or something else. We need these properties because they capture two different concepts: one is just a tag, and one is categorizing malware, threat actors, etc.

* JMG: This is almost where namespaces are very useful so you can categorize your custom properties accordingly.

* Straw poll: 1 for addressing this issue in CSD01, 6 for pushing this out to CSD02.