OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [cti] Idea for Internationalization

I concur with Trey and Rob here as far as CybOX - given the nature of Observables as describing the properties of some artifact, I’m not sure if it makes sense to define a translation for its string-based fields, as this isn’t the same use case as translating a human-entered piece of text in STIX (e.g., Title or Description). 


On 2/8/16, 6:55 AM, "cti@lists.oasis-open.org on behalf of Coderre, Robert" <cti@lists.oasis-open.org on behalf of rcoderre@verisign.com> wrote:

>It makes complete sense to have translations available for top level objects, and I agree with Ryu that that it also makes sense to include the translations in the same object.  In most cases (my subjective view) the translations will come from the same producer.  If an independent third party is translating content, then it should be a separate object and referenced back to the original.
>As for CybOX observables, I think these would be independent objects, primarily for the reasons Trey mentions, which is they are specific to a particular region/language and will have enough subtle differences as to warrant that distinction.
>-----Original Message-----
>From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Trey Darley
>Sent: Monday, February 08, 2016 6:43 AM
>To: Masuoka, Ryusuke
>Cc: cti@lists.oasis-open.org
>Subject: Re: [cti] Idea for Internationalization
>On 08.02.2016 08:00:55, Masuoka, Ryusuke wrote:
>> 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
>> -----
>I was tracking along with this I18N discussion right up until now.
>Does it make sense to provide translations of CybOX observables?
>Taking Ryusuke's example, assume that I'm a threat actor using an identical malicious payload to target victims in multiple languages.
>If I send out a phishing mail entitled "医療費通知", then the payload will be in Japanese. If I'm also targeting French-speakers, 1) the odds are minimal that I'll translate the file name exactly "Frais médicaux Notez" and even supposing that I do translate the filename exactly that way, the payload is going to be in French and so there's no chance in hell of the file hashes matching.
>I18N makes total sense to me at the level of STIX TLOs with fields humans are likely to read. I don't see it providing much value at the CybOX observable level compared to the amount of complexity it will introduce.
>We want to cater to humans, obviously, but if we make observables so complex as to practically preclude machine-parsing of them, then why not just send an old-fashioned email instead of using STIX/CybOX?
>Trey Darley
>Senior Security Engineer
>4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430 Soltra | An FS-ISAC & DTCC Company www.soltra.com
>"In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away."
>--RFC 1925

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]