Hi, Bret, John, all,
I have given a further thought on the subject during the weekend
and I came to believe that it is not just of simple implementation,
but also conceptually or semantically simple and natural
to have all the translations within the
May it be a title, a description, a filename, a subject of email, etc.,
treating a translation as another property of the same object or
subproperty of the text object would be simpler and more natural
than treating the translation as another object.
For example, if it is a file object, it would be
-----
Case (A)
-----
File Object:
ID: A123
File Name (Original - JA):
“ ????? ”
File Name (Translation - EN):
“ Medical expenses notice ”
File Name (Translation - FR):
“ Frais m é dicaux
Notez ”
File Extension: PDF
Size in Bytes: 410,314
Hashes:
Hash Name: SHA1
Hash Value: 1234567890123456789012345678901234567890
-----
Or something like
-----
Case (B)
-----
File Object:
ID: B123
File Name: {Text:
(Original - JA):
“ ????? ”
(Translation - EN):
“ Medical expenses notice ”
(Translation - FR):
“ Frais m é dicaux
Notez ”
}
File Extension: PDF
Size in Bytes: 410,314
Hashes:
Hash Name: SHA1
Hash Value: 1234567890123456789012345678901234567890
-----
rather than three objects like
-----
Case (C)
-----
File Object:
ID: C123
File Name:
“ ????? ”
File Extension: PDF
Size in Bytes: 410,314
Hashes:
Hash Name: SHA1
Hash Value: 1234567890123456789012345678901234567890
File Object File Name Translation Object:
EN:
“ Medical expenses notice ”
Referring: C123
File Object File Name Translation Object:
FR:
“ Frais m é dicaux
Notez ”
Referring: C123
-----
Case (C) looks unnecessarily complex and unnatural for me.
When someone want to link campaign, TTP, Threat Actor, and other
Objects in English to this File Object, you can just link A123 or B123
in case of (A) or (B) respectively and its English filename is readily available
in the referred object. In case of (C), you need to link them to the original C123.
If you want to find the filename in English, you have to search
the database for
“ File Object File Name Translation Object ”
with EN property. IMHO, I feel the latter is not simple/natural/efficient.
It may be difficult, or even impossible with home-grown scripts.
I used to work on pervasive/ubiquitous computing applications
based on the Semantic Web. At that time, I used a decent semantic
engine/database (Jena) and it is an easy task to follow the linked objects.
However, I am afraid that it is not always the case (in particular, for
home grown scripts) that there is such a database available.
Regards,
Ryu
From:
cti@lists.oasis-open.org [mailto:
cti@lists.oasis-open.org]
On Behalf Of Jordan, Bret
Sent: Saturday, February 06, 2016 1:20 AM
To: Wunder, John A.
Cc:
cti@lists.oasis-open.org Subject: Re: [cti] Idea for Internationalization
From what we have heard, it seems very common that someone will get a report or an object and add some translations to it. That was one of Ryu's original use-cases..
I think it is also important to note that someone should not be looking at the raw JOSN packages. A tool could easily merry the various translations and original documents in one single pane of glass UI. So an end user
or analyst would never need to know that they were multiple packages.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Feb 5, 2016, at 09:12, Wunder, John A. <
jwunder@mitre.org > wrote:
The more I think about it, the more I agree that within the object might be easier for implementors. Yes, it’s extra ugliness for single-language content but
tools will abstract that away and it may be simpler to manage than the separate objects. It’s kind of a toss up really, I don’t have a preference.
That said, I don’t think that approach works for capturing third-party translations (translations by someone other than the original producer). Each org doing
a translation would need to issue a new version of the object with their translation added, which then bifurcates the TLOs. The separate “translation” object avoids that. How common is that scenario?
John
From: <
cti@lists.oasis-open.org >
on behalf of "Masuoka, Ryusuke" <
masuoka.ryusuke@jp.fujitsu.com >
Date: Friday, February 5, 2016 at 2:37 AM
To: "Jordan, Bret" <
bret.jordan@bluecoat.com >
Cc: Jason Keirstead <
Jason.Keirstead@ca.ibm.com >, Terry MacDonald <
terry@soltra.com >,
"
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >, "Wunder, John A." <
jwunder@mitre.org >
Subject: RE: [cti] Idea for Internationalization
Hi,
Thank you for compiling the key points.
I thought through it, but I think it is much simpler/easier to handle
if multiple texts are put together in a single object
rather than they are separate at object level.
I am looking at a report in English by iSIGHT Partners on Cyber Attack on Japan.
There are filenames of lure attachments in Japanese (original/real) and their
translations in English. Another similar report in English has an email title along with
its translation in English next to it. That report also has a Windows pathname
in Chinese (not Japanese) found in a binary along with its translation in English.
(If you have access to iSIGHT Partners reports, they are 15-00007028 and 15-00009810.)
If those texts in Japanese (or in Chinese) and English are in separate objects,
it would be difficult to provide useful view for users even if they are related using Relations.
-----
By the way, this may not be related to language code thing, but just for your information.
there are more subtle cases. Unicode uses CJK Unified Ideographs
(
https://en.wikipedia.org/wiki/CJK_Unified_Ideographs ).
One can use
Chinese ideographs in Japanese sentence. Some attacker uses,
in a phishing email subject, a Chinese character of the same meaning,
but of an ideograph different from the one used in Japan.
-----
Regards,
Ryu
From:
cti@lists.oasis-open.org [ mailto:
cti@lists.oasis-open.org ] On
Behalf Of Jordan, Bret
Sent: Wednesday, February 03, 2016 11:52 PM
To: Masuoka, Ryusuke/ ????
Cc: Jason Keirstead; Terry MacDonald;
cti@lists.oasis-open.org ; Wunder, John A.
Subject: Re: [cti] Idea for Internationalization
Obviously there is a lot to figure out, and the proposed idea is to use a relationship or something like it.
The key points are that:
1) There would be only one real indicator (using indicators as an example) in what ever language you wanted.
2) The language of that indicator would be identified by a "lang" field.
3) Translations of the indicator would some how be tied to that indicator.
4) Campaigns, TTPs, threat actors, etc would be tied to the "real" indicator regardless of the language it was in.
5) Under normal conditions if the producer of the indicator also produced translations, you would get them all at one time.
6) In TAXII this would allow you to ask for an indicator and ask for specific translations if they exist.
Would something like this work for you?
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Feb 3, 2016, at 00:35, Masuoka, Ryusuke <
masuoka.ryusuke@jp.fujitsu.com > wrote:
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
<image001.gif> 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
<image001.gif> 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