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

[Sean Barnum <sean.barnum@FireEye.com>]

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.