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

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

I agree with @JMG in that if we don't go
the distance and define this in a way that it is inter-operable (which
I am not sure there is a sane path to, FWIW), then I would prefer to just
leave it out totally and let individuals and trust groups communicate this
however they want using labels and/or custom properties.

There is little value I see in having
a single field saying "AES128-CBC",
as it is not enough information for a consumer to do anything with unless
they have some other information about how the producer encrypted the data.

There is no reason to add more metadata
fields to STIX that do not lead to any type of interoperability. The whole
purpose of having a standard is to make software inter-operable.

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security

Without data, all you are is just another person with an opinion - Unknown




From:      
 "Katz, Gary CTR
DC3\\DCCI" <Gary.Katz.ctr@dc3.mil>
To:      
 "Wunder, John
A." <jwunder@mitre.org>, "cti-cybox@lists.oasis-open.org"
<cti-cybox@lists.oasis-open.org>
Date:      
 10/12/2017 10:12 AM
Subject:    
   RE: [cti-cybox]
File/Artifact Encryption & Archive Properties
Sent by:    
   <cti-cybox@lists.oasis-open.org>

---

It depends on the use case.  Are we *describing*
encryption to exchange samples, or are we also using it to describe the
TTPs of actors who are encrypting exfiltration data, or using it to describe
how certain data within a malware sample is encrypted, or how the C2 connection
between malware and a C2 node is encrypted?

If we're only using it for the first use case, I'd agree.  If we are
using it for any of the other use cases we'll need to be much more verbose.

-----Original Message-----
From: cti-cybox@lists.oasis-open.org [mailto:cti-cybox@lists.oasis-open.org]
On Behalf Of Wunder, John A.
Sent: Thursday, October 12, 2017 8:31 AM
To: cti-cybox@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti-cybox] File/Artifact Encryption &
Archive Properties

So I’m going to play the “I’m just a caveman” card.

Should STIX just standardize on a few constrained methods of encryption,
rather than leaving this wide open? I know for *describing* encryption
we need to be able to represent the full range because that’s what might
be used in the wild, but when we’re *using* it to exchange samples, can’t
we just lock it down a bit to what’s most common and directly enumerate
the options? Then we can just define what those few are and how to use
them rather than trying to comprehensively support representing how to
decrypt stuff across a variety of different tools and algorithms.

John

On 10/11/17, 6:48 PM, "cti-cybox@lists.oasis-open.org on behalf of
John-Mark Gurney" <cti-cybox@lists.oasis-open.org on behalf of
jmg@newcontext.com> wrote:

    Kirillov, Ivan A. wrote this message on Fri, Oct 06, 2017
at 16:44 +0000:
    
    Defining encryption such that it is interoperable is difficult.
 If we
    want to do this, we can, but it will take a lot of work.
 We can of
    course hand wave this, but it does mean that there is likely
to be zero
    interoperation using this feature.
    
    If we want to standardize this such that it'll be interoperable,
then
    I'm willing to help work on this, but we need to define it
properly,
    and that is more than just saying aes128-cbc...
    
    > Two more items of note:
    > 
    > 1. Earlier this week, Sean pointed me to the UCO structure
for encrypted streams [1] – see example JSON here [2]. The main difference
between our implementation and theirs is that our encryption algorithm
vocabulary includes algorithm (method) and mode, whereas their structure
breaks these up into separate properties. In addition, they have a property
for capturing the initialization vector (IV) used.
    > 2. We discussed the current issues and UCO’s approach
during today’s additional working call. The consensus seems to be that
our current vocabulary that captures encryption algorithm + mode is reasonable,
since this is simpler than splitting the two out into separate properties,
and this is also how this data is represented in other contexts. However,
there seemed to be support for adding IV as a separate property, since
this is a useful facet to capture. Also, we discussed that another use
case is capturing how threat actors misuse/poorly implement encryption,
particularly for attribution, so it would be nice to have some examples
of this.
    > 
    > Anyhow, based on some of these recent discussions, I’m
wondering if we can implement encryption as a dictionary with an associated
standard vocabulary. That way, we can re-use this structure wherever we
need to characterize encryption of a STIX Cyber Observable Object. As a
strawman, it could look something like:
    > 
    > {
    >   "algorithm":"AES128-CBC",
    >   "init_vector_hex":"1122FFAA",
    >   "decryption_key":"foobar"
    > }
    
    I disagree w/ using IV, or restricting the additional tags
to only be
    IV..  So algorithms, like AES-GCM uses a nonce (which
though serve
    similar purposes to an IV, has a very specific and different
meaning
    to IV)...
    
    As we define each cipher mode, we can define that the IV
is the first
    16 bytes, or what ever, as needed, and there is no need for
a special
    property for this.
    
    Also, we haven't even discussed padding here either.  There
are many
    different ways to pad messages as needed (or lack of padding
in the
    case of CTR mode and other stream ciphers...  NIST recommends
adding
    a binary 1, and as many binary 0's as needed, while TLS uses
bytes
    whose value equals the length of the padding.
    
    > On 10/4/17, 11:51 AM, "Trey Darley" <trey@newcontext.com>
wrote:
    > 
    >     On 04.10.2017 15:40:03, Kirillov, Ivan
A. wrote:
    >     > > An encrypted zip file is different
than just encrypting (and
    >     > > compressing) the file contents.
Doing this would lose the
    >     > > mime_type of the file being
compressed in the archive (if this is
    >     > > important).
    >     > 
    >     > That’s true, but since we’re discussing
the Artifact Object in this
    >     > case, I don’t think we care about
the contents as much as the
    >     > container (the actual “artifact”).
If you need to characterize the
    >     > contents of an archive, you can still
using the existing File Object
    >     > w/ archive-file-extension for this
purpose.
    >     > 
    >     
    >     Exactly.
    >     
    >     > 
    >     > Also, I’m in agreement with Sean
and others that it probably makes
    >     > the most sense to just add a new
entry of “unspecified” to the
    >     > encryption-algo-ov, since this would
cover all of our associated use
    >     > cases.
    >     > 
    >     
    >     I just added that to the encryption-algo-ov
in STIX 2.1, Part 3.
    
    -- 
    John-Mark
    
    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS
TC that 
    generates this mail.  Follow this link to all your TCs
in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php