cti-cybox message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-cybox] RE: [Non-DoD Source] Re: [cti-cybox] File/Artifact Encryption & Archive Properties
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Sean Barnum <sean.barnum@FireEye.com>
- Date: Thu, 12 Oct 2017 15:46:28 -0300
I don't see how adding encryption_algorithm
and decryption_key to a sample helps
anyone.
As has been pointed out many times -
this is not enough information for a consumer to do anything with whatsoever
regarding the sample.
If someone wants to add encryption_algorithm
to the object as some kind of simple
piece of metdata an analyst can pivot on - fine - but I very firmly do
not agree we should add "decryption_key". We would need a heck
of a lot more discussion to come up with a workable proposal.
-
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:
Sean Barnum <sean.barnum@FireEye.com>
To:
Jason Keirstead <Jason.Keirstead@ca.ibm.com>,
"Kirillov, Ivan A." <ikirillov@mitre.org>
Cc:
"cti-cybox@lists.oasis-open.org"
<cti-cybox@lists.oasis-open.org>, "Katz, Gary CTR DC3\\DCCI"
<Gary.Katz.ctr@dc3.mil>, "Wunder, John A." <jwunder@mitre.org>
Date:
10/12/2017 03:42 PM
Subject:
Re: [cti-cybox]
RE: [Non-DoD Source] Re: [cti-cybox] File/Artifact Encryption & Archive
Properties
Just to give a little clarity, the use
case Gary described when he said it takes long reports to convey is one
of very deep analysis of use of encryption. While it is the sort of thing
some analysts due day to day it is not a broadly common use case.
On the other hand, threat intel that wants
to simply say this chunk-o-bits (file, memory region, network capture,
etc.) are encrypted with AES256 (or whatever) is very common and conveying
an encryption key (password, etc.) that was used to encrypt a chunk-o-bits
is also very common. In the vast majority of cases it does not need to
be more detailed than this. It is typically used to characterize the sort
of encryption used by a ThreatActor, Campaign, Malware, etc. or to characterize
use/reuse of particular passwords (or password structure approaches) by
a ThreatActor, Campaign, Malware, etc.
It is basic threat intel.
So, I would suggest breaking the first
bullet of Jason’s TL;DR below into two separate bullets: the truly high-level
simple use case I describe above and the much deeper sort of analysis Gary
was describing.
I would agree that for now tackling the
deep encryption analysis _expression_ is out of scope for us.
I would however assert that the simple
case is definitely within scope and justifies the proposed addition of
encryption_algorithm and decryption_key to the Artifact Object.
It is much more appropriate on the Artifact
Object anyway as it is describing something about the content itself.
I am fine either way on whether we try
to support the encryption details of the sample sharing use case.
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E: sean.barnum@fireeye.com
From: <cti-cybox@lists.oasis-open.org>
on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, October 12, 2017 at 1:35 PM
To: "Kirillov, Ivan A." <ikirillov@mitre.org>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>,
"Katz, Gary CTR DC3\DCCI" <Gary.Katz.ctr@dc3.mil>, "Wunder,
John A." <jwunder@mitre.org>
Subject: Re: [cti-cybox] RE: [Non-DoD Source] Re: [cti-cybox] File/Artifact
Encryption & Archive Properties
That is the point of this email trail
though - "for use cases such as
sharing malware samples in an encrypted Zip archive", that use case
doesn't fly - that is what we have been discussing. There is not enough
information here for a recipient to have enough knowledge to decrypt anything.
TL;DR
- Metadata to communicate high level details about encryption of samples
- fine by me (although Gary's comment that they in reality require long
reports to communicate this don't give me much confidence in it's utility)
- Metadata to communicate *actual decryption information - not fine by
me as it requires a heck of a lot more thought, discussion, and inevitably
more complexity than we have discussed here.
-
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: "Kirillov,
Ivan A." <ikirillov@mitre.org>
To: Jason
Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "cti-cybox@lists.oasis-open.org"
<cti-cybox@lists.oasis-open.org>, "Katz, Gary CTR DC3\\DCCI"
<Gary.Katz.ctr@dc3.mil>, "Wunder, John A." <jwunder@mitre.org>
Date: 10/12/2017
02:01 PM
Subject: Re:
[cti-cybox] RE: [Non-DoD Source] Re: [cti-cybox] File/Artifact Encryption
& Archive Properties
Well, the thing is that we already have encryption_algorithm on File and
there are some use cases for keeping it there (for instance, capturing
that Malware drops an encrypted file). So with #2, we’d just be adding
it to Artifact and moving decryption_key there for use cases such as sharing
malware samples in an encrypted Zip archive.
Regards,
Ivan
From: <cti-cybox@lists.oasis-open.org> on behalf of Jason Keirstead
<Jason.Keirstead@ca.ibm.com>
Date: Thursday, October 12, 2017 at 10:37 AM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>,
"Katz, Gary CTR DC3\DCCI" <Gary.Katz.ctr@dc3.mil>, John
Wunder <jwunder@mitre.org>
Subject: Re: [cti-cybox] RE: [Non-DoD Source] Re: [cti-cybox] File/Artifact
Encryption & Archive Properties
I am OK with #1 and #3, but I thought we just agreed that we don't want
to do #2 at this point in time.
-
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: "Kirillov,
Ivan A." <ikirillov@mitre.org>
To: "Katz,
Gary CTR DC3\\DCCI" <Gary.Katz.ctr@dc3.mil>, Jason Keirstead
<Jason.Keirstead@ca.ibm.com>, "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-cybox@lists.oasis-open.org"
<cti-cybox@lists.oasis-open.org>
Date: 10/12/2017
01:32 PM
Subject: Re:
[cti-cybox] RE: [Non-DoD Source] Re: [cti-cybox] File/Artifact Encryption
& Archive Properties
Sounds good to me – I would echo the points that we’d want whatever we
do to be implementable and usable for STIX users today. If don’t have
the confidence that we can accurately and fully describe encryption today
for these various use cases, then we shouldn’t try to do so for 2.1.
So that said, are we OK with the original proposal, namely:
- Deprecating is_encrypted and decryption_key
from the File Object
- Adding encryption_algorithm and decryption_key
to the Artifact Object
- Expanding the encryption-algo-ov to include
some additional missing algorithms (e.g., AES-256, RC4, RC5, etc.)
Regards,
Ivan
From: <cti-cybox@lists.oasis-open.org> on behalf of "Katz,
Gary CTR DC3\DCCI" <Gary.Katz.ctr@dc3.mil>
Date: Thursday, October 12, 2017 at 10:24 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, John Wunder
<jwunder@mitre.org>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: [cti-cybox] RE: [Non-DoD Source] Re: [cti-cybox] File/Artifact
Encryption & Archive Properties
I’m fine with that. I don’t think that we would be using the fields
anytime soon. When we usually describe the encryption used by the
adversary it’s in a long report and not something we’d try to move into
being machine readable.
The one thing I do think would be useful for attribution and pivoting is
the encryption implementation, especially unusual encryption implementations
since that would point to the same malware author or similar TTPs. I
don’t think this is something we need in the next release, to Jason’s
point we’ve got bigger fish to fry, but it is something that I would be
interested in seeing for a future release.
From: cti-cybox@lists.oasis-open.org [mailto:cti-cybox@lists.oasis-open.org]
On Behalf Of Jason Keirstead
Sent: Thursday, October 12, 2017 11:09 AM
To: Wunder, John A. <jwunder@mitre.org>
Cc: Katz, Gary CTR DC3\DCCI <Gary.Katz.ctr@dc3.mil>; cti-cybox@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti-cybox] File/Artifact Encryption
& Archive Properties
I don't know enough about the current usage by practitioners in the field
to comment on #1 style use so I will stay out of that...
But my opinion on #2 is to just stay out of this business totally, especially
at the current time. I don't think we can do it justice in a short time
frame, and we have a lot more important things to tackle than this.
Sent from IBM Verse
Wunder, John A. --- 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
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]