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: "Kirillov, Ivan A." <ikirillov@mitre.org>
- Date: Thu, 12 Oct 2017 13:35:34 -0300
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]