Hi, If we go with the relationship, ... (1) Do we always have to decide which is original (and others translations)? (I am thinking of providing an object texts in multiple languages simultaneously at the time of creation. ja/en (in case of Japan), en/fr/de (in case of EU countries), etc.) (2) Are we going to create additional translation types for all types with texts? (Ex. “ indicator-translation ” for “ indicator ” , and so on.) Regards, Ryu From:
cti@lists.oasis-open.org [mailto:
cti@lists.oasis-open.org] On Behalf Of Jason Keirstead Sent: Wednesday, February 03, 2016 12:47 AM To: Terry MacDonald Cc: Jordan, Bret;
cti@lists.oasis-open.org; Wunder, John A. Subject: RE: [cti] Idea for Internationalization I like the relationship concept better because it makes it easier for me to totally ignore translations if I don't care about them. If the translation is inside the original object, I have to consume and parse it when I may not care. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Terry MacDonald ---02/02/2016 11:43:56 AM---Hi Jason, That was Bret and Johns option 3 as I understand it. I don’t think it requires a relations From: Terry MacDonald <
terry@soltra.com > To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Jordan, Bret" <
bret.jordan@bluecoat.com >, "Wunder, John A." <
jwunder@mitre.org >, "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org > Date: 02/02/2016 11:43 AM Subject: RE: [cti] Idea for Internationalization Hi Jason, That was Bret and Johns option 3 as I understand it. I don’t think it requires a relationship object to link them as it isn’t something that requires a confidence level. John used a direct ref to the translation object, which makes sense as the translation object creator would be the one also linking the object – so they don’t need the confidence values that the relationship provides, and third-parties don’t need to assert that the object is a translation of the original object – that’s something the translation object producer can do. e.g. (from John’s earlier post - bolded object reference shown) It would look something like this: [ { “type”: “indicator”, “id”: “indicator—UUID”, “lang”: “en-US”, “title”: “English title”, }, { “type”: “indicator-translation”, “id”: “indicator-translation—UUID”, “object_ref”: “indicator—UUID” “lang”: “jp”, “title”: “Japanese Title” } ] Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206
terry@soltra.com From: Jason Keirstead [ mailto:
Jason.Keirstead@ca.ibm.com ] Sent: Wednesday, 3 February 2016 2:36 AM To: Terry MacDonald <
terry@soltra.com > Cc: Jordan, Bret <
bret.jordan@bluecoat.com >; Wunder, John A. <
jwunder@mitre.org >;
cti@lists.oasis-open.org Subject: RE: [cti] Idea for Internationalization Instead of re-issuing the TLO at all, I don't get why we can't just have a "translation" TLO. This avoids having to re-issue objects at all. All IDs stay the same. Also allows any party to add translations. Here is the concept. { "type": "stix-package", "id": "stix-package--ad3d029f-6fe7-4923-aafc-3b69aed32365", "lang" :"en-US" “title”: "My Campaign" } { "type":"translation", "id":"stix-translation-- 78ac772a-ba02-4693-9b0b-39d568bc8514", "field":"title", "lang":"jp", "value":" ?????? " } "relationships" : [ { "id" : "relationship--1" , "type" : "relationship" , "from" : " stix-package--ad3d029f-6fe7-4923-aafc-3b69aed32365 " , "to" : " stix-translation-- 78ac772a-ba02-4693-9b0b-39d568bc8514 " , "relationship_value" : "translation" }, - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Terry MacDonald ---02/02/2016 11:29:12 AM---Hi Brett, “The solution that Ryu and Terry have called out, work, but only for the original producer From: Terry MacDonald <
terry@soltra.com > To: "Jordan, Bret" <
bret.jordan@bluecoat.com >, "Wunder, John A." <
jwunder@mitre.org > Cc: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org > Date: 02/02/2016 11:29 AM Subject: RE: [cti] Idea for Internationalization Sent by: <
cti@lists.oasis-open.org > Hi Brett, “ The solution that Ryu and Terry have called out, work, but only for the original producer. Everyone that wants to add a translation, or fix a translation, would have to re-issue and re-version the entire TLO. Which will break linkages to campaign and threat actors as the translations grow organically by themselves.” Not true, if we use the incremental versioning method which was described in the TWIGS proposal to the F2F. That * would * be true if we used major versioning, but in TWIGS we removed major versioning because of the difficulties it caused in situations like this. If we do incremental versioning as we have written in the TWIGS proposal, then the Object ID doesn’t change with new versions of the object. Which means that Option 1 (kind of what Ryu and I proposed) doesn’t result in broken linkages to campaigns and threat actors. This also doesn’t result in losing the ability to track source, as another one of the TWIGS proposal ‘rules’ also applies here – that only content producers can update the objects they release. This also does means that translations can only be released by the content producers as well, which is not optimal. I prefer Option 1 but can get on-board with Option 3 if that’s what others prefer. A translation only object related to the root object does introduce a greater size, but if it is an object that allows being partially filled then that will reduce the extra characters wasted. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206
terry@soltra.com