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: Trey Darley <trey@newcontext.com>
- Date: Fri, 13 Oct 2017 12:37:46 -0300
OK so now we're back.
We need agreement first on which use
case we're trying to solve here with these fields. Sean is trying to solve
a very different use case than you are.
We need to be agreed on what we are
even trying to solve if these fields are going to be in the spec, because
we need clear text on how to use them. As it stands, it is clear right
now that the fields would just add confusion as some people would use them
to communicate one thing, and some another. Let's start there. Once that
is agreed upon, *if* we agree that the use case is as you have below (the
sharing of actual encrypted files) then I can again get into all the reasons
this is much more complicated.
-
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:
Trey Darley <trey@newcontext.com>
To:
Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc:
Sean Barnum <sean.barnum@FireEye.com>,
"cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>,
"Katz, Gary CTR DC3\\DCCI" <Gary.Katz.ctr@dc3.mil>, "Kirillov,
Ivan A." <ikirillov@mitre.org>, "Wunder, John A."
<jwunder@mitre.org>
Date:
10/13/2017 11:42 AM
Subject:
Re: [cti-cybox]
RE: [Non-DoD Source] Re: [cti-cybox] File/Artifact Encryption & Archive
Properties
Sent by:
<cti-cybox@lists.oasis-open.org>
On 12.10.2017 15:46:28, Jason Keirstead wrote:
> 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.
>
All day, every day malware researchers share samples around in
encrypted zip files. Countless emails fly across the wire along the
lines of, "Hey, have a look at this, let me know what you think. The
password is 'infected'."
That's precisely the use case we're attempting to address with the
proposed changes to the Artifact object. Please help me understand why
that's so complicated to do this in STIX.
If our proposed approach for sharing defanged malware samples is truly
unworkable, as an alternative I suggest adding an optional boolean
property to the Artifact object `is_rot13`. ;-)
--
Cheers,
Trey
++--------------------------------------------------------------------------++
Director of Standards Development, New Context
gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338
++--------------------------------------------------------------------------++
--
"A project is sustainable if it is cheap enough to be the first of
a
series continuing indefinitely into the future. A project is
unsustainable if it is so expensive that it cannot be repeated without
major political battles. A sustainable project marks the beginning of
a new era. An unsustainable project marks the end of an old era."
--Freeman Dyson
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]