Re: [cti-cybox] File/Artifact Encryption & Archive Properties

[John-Mark Gurney <jmg@newcontext.com>]

Sean Barnum wrote this message on Tue, Sep 26, 2017 at 15:27 +0000:
> I can see the distinction you describe and believe it is valid but I personally think the value in supporting that distinction is likely outweighed by the confusion it may introduce.
> I also think explicitly having the distinction you make below (“with “unspecified” you may know the encryption algorithm but may not wish to share it, whereas with “unknown” it’s truly not known.”) would violate the intended ambiguity of the use case where a producer does not want to expose their capabilities, sources and methods in encryption analysis. For them, asserting “unspecified” (and avoiding use of “unknown”) means they actually know how to analyze the encryption, and asserting “unknown” (instead of “unspecified) would be stating something not true. The use case described is  premised on their desire to not assert they actually know how to analyze the encryption.
> 
> “unspecified” can be specified to mean encryption present but algorithm is unspecified (supporting both the case where you don’t know it and the case where you know it but do not want to share it). I think the first part of this is much more important than the second part in the parenthetical.
> 
> Personally, I would suggest adding just “unspecified” and not “unknown”.

I agree w/ unspecified over unknown.  Unspecified is technically a superset of unknown per below...

> On 9/26/17, 11:17 AM, "Kirillov, Ivan A." <ikirillov@mitre.org> wrote:
> 
>     This (having an additional vocabulary entry) makes sense to me, and I was actually thinking along the same lines. Besides “unspecified”, should we also add an “unknown” entry? I think the context between the two is different – with “unspecified” you may know the encryption algorithm but may not wish to share it, whereas with “unknown” it’s truly not known.
> 
>     Regards,
>     Ivan
> 
>     On 9/26/17, 9:12 AM, "Paul Patrick" <Paul.Patrick@FireEye.com> wrote:
> 
>         Sean beat me to responding as I was going to make the same suggestion.  The suggested approach has the additional benefit of avoiding an inconsistent state where someone forgets to set is_encrypted = true and supplies a value to encryption_algoritm.
> 
> 
>         Paul Patrick
> 
>         On 9/26/17, 11:06 AM, "cti-cybox@lists.oasis-open.org on behalf of Sean Barnum" <cti-cybox@lists.oasis-open.org on behalf of sean.barnum@FireEye.com> wrote:
> 
>             BTW, one other option discussed back at the time was to include an “unspecified” entry in the encryption_algorthim vocabulary.
>             Using this approach rather than including is_encrypted=true and not including encryption_algortithm you would simply include encryption_algorithm=unspecified.
>             This approach removes the need for the is_encrypted property.
>             At the time it was discussed, the parties involved felt that an explicit is_encrytped property was less ambiguous and open to misinterpretation.
>             Given our current discussions maybe we want to revisit that determination.
>             As long as the use of “unspecified” is very clearly described in the spec and unambiguous, FireEye would be willing to support this approach.
>             Our concern is that the use case is possible to cover and believe either approach would do so.
> 
>             Sean Barnum
>             Principal Architect
>             FireEye
>             M: 703.473.8262
>             E: sean.barnum@fireeye.com
> 
>             On 9/26/17, 10:54 AM, "cti-cybox@lists.oasis-open.org on behalf of Sean Barnum" <cti-cybox@lists.oasis-open.org on behalf of sean.barnum@FireEye.com> wrote:
> 
>                 The use case was as Greg briefly described and led to Ivan’s email I responded to.
>                 Namely, situations where analysts wish to assert that a particular file or artifact is encrypted without specifying an encryption algorithm or mechanism (typically either because they do not have the information or because they have it but do not want to share it).
> 
>                 That use case was raised by multiple parties during CybOX development which led to is_encrypted being added.
> 
>                 I am not personally an expert on these matters so will likely run out of runway quickly if pressed to represent the knowledge of all the experts who asserted the need.
>                 I do recall two of the example situations given where they know it is encrypted but do not know the encryption algorithm.
>                 - One was a situation where particular tooling can detect encryption (I think it was some kind of differential entropy analysis) and sometimes also determine the algorithm but other times only let you know that encryption is present but not identify the algorithm used.
>                 - Two was a situation where some form of non-technical intelligence source (e.g., humint) tells you something is encrypted but not provide information on algorithm used.
>                 I also recall one example situation given where you actually know the algorithm used but do not want to share it. The situation they gave was where the producer does not want to expose their capabilities, sources and methods in encryption analysis.
> 
>                 At the time, some parties argued that you would know it was encrypted by the presence of an encryption_algorithm property and that is_encrypted was not necessary. This was discussed at length and the consensus was that the above use case made the is_encrypted property necessary.
>                 We would assert that it is still relevant and necessary.
> 
>                 Sean Barnum
>                 Principal Architect
>                 FireEye
>                 M: 703.473.8262
>                 E: sean.barnum@fireeye.com
> 
>                 On 9/26/17, 10:22 AM, "Trey Darley" <trey@newcontext.com> wrote:
> 
>                     On 25.09.2017 13:59:08, Sean Barnum wrote:
>                     > Yes. This specific use case is what led to the is_enrypted boolean
>                     > property
>                     >
> 
>                     Hi, Sean -
> 
>                     This thread began with Ivan asking if there are real-world use cases
>                     this property, absent additional context. The mere existence of the
>                     property is not a use case. Please enlighten us.
> 
>                     --
>                     Cheers,
>                     Trey
>                     ++--------------------------------------------------------------------------++
>                     Director of Standards Development, New Context
>                     gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
>                     ++--------------------------------------------------------------------------++
>                     --
>                     "One size never fits all." --RFC 1925
> 
> 
>                 This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
> 
> 
>             This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
> 
> 
>         This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
> 
> 
> 
> 
> This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

-- 
John-Mark