[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-cybox] File/Artifact Encryption & Archive Properties
| From: | "Wunder, John A." <jwunder@mitre.org> |
| To: | "Katz, Gary CTR DC3\\DCCI" <Gary.Katz.ctr@dc3.mil>, cti-cybox@lists.oasis-open.org |
| Date: | Thu, Oct 12, 2017 10:31 AM |
| Subject: | Re: [cti-cybox] File/Artifact Encryption & Archive Properties |
Yeah this is what I was thinking, but maybe I wasn’t totally clear on what I was thinking we could do. We have two different use cases here, can we solve them in different ways?
1. For describing encryption used by the adversary, is our existing vocabulary sufficient? I know it doesn’t have all of the detail necessary to actually decrypt data encoded with it, but is it sufficient for the threat intel use case?
2. For representing samples that we actually do need to decrypt, can we standardize on like the top 3 most commonly used approaches and just require people use those when sharing samples in STIX.
John
On 10/12/17, 9:12 AM, "Katz, Gary CTR DC3\DCCI" <cti-cybox@lists.oasis-open.org on behalf of Gary.Katz.ctr@dc3.mil> wrote:
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]