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

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

... But that is the problem I am pointing
out.

Having a blob of bytes and knowing it
is encrypted with AES-256 is not sufficient to open it. I have to know
that it is encrypted using Zip encryption with AES-256, or 7zip encryption
with AES-256, as these are different things.

-
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>
Date:      
 09/25/2017 10:40 AM
Subject:    
   Re: [cti-cybox]
File/Artifact Encryption & Archive Properties

---

Thanks for the feedback all – I agree
with Jane that we need a diagram or description (probably) of when to use
the File vs. Artifact Objects. 
 
> I like the idea but I wonder if
"encryption_algorithm" should be "encryption_method".
 
Well, right now this property refers to
the actual algorithm (e.g., AES128-CBC, RSA, etc. via the Encryption Algorithm
Vocabulary [1]) used to encrypt the data in the file, so I think keeping
the original name would be preferable since it doesn’t capture the application
method.
 
[1] https://docs.google.com/document/d/1fWHWyo9OBOUVDKEs0HsMKIWqR8HTl3P8aDyM5Mz3iSM/edit#heading=h.h5b9uravt8oh
 
Regards,
Ivan
 
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Monday, September 25, 2017 at 5:55 AM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] File/Artifact Encryption & Archive Properties
 
I like the idea but I wonder if "encryption_algorithm"
should be "encryption_method".

What do you want someone to put in that field? "AES-256", or
something that also describes the application method used to encrypt the
file?


-
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:        "cti-cybox@lists.oasis-open.org"
<cti-cybox@lists.oasis-open.org>
Date:        09/22/2017
04:50 PM
Subject:        [cti-cybox]
File/Artifact Encryption & Archive Properties
Sent by:        <cti-cybox@lists.oasis-open.org>

---

Recently, Trey and I proposed some updates to the STIX 2.1 Artifact Object
that came about as a result of the work we’ve been doing on the Malware
SDO. Namely, we’ve been trying to support the use case around the exchange
of “defanged” malware samples that are commonly stored in password encrypted
archive files. Thus, we’ve proposed the addition of the “encryption_algorithm”
and “decryption_key” properties to the Artifact Object. 
 
However, Paul Patrick and some others rightly pointed out that we have
some duplicate properties on the base File Object, including “is_encrypted”,
“encryption_algorithm”, and “decryption_key”. This is especially problematic
because the File Object can reference an Artifact to describe its binary
contents via the “contents_ref” property. After thinking about this some
more and discussing it on today’s working call, we’re proposing the following
changes in STIX 2.1 to help address this potential duplication:

• Deprecate the following properties on the File Object:
  • is_encrypted: This property is simply redundant because it’s clear that the file is encrypted if the “encryption_algorithm” property is specified.
  • decryption_key: It doesn’t seem useful to capture a decryption key as purely metadata and without the corresponding encrypted data that it goes with.
• Add the previously discussed “encryption_algorithm” and “decryption_key” properties to the Artifact Object. We recognize that “encryption_algorithm” is the same property as on the base File Object, but there may be cases where you want to share an encrypted Artifact (such as some data dumped from memory) without a corresponding File Object. Also, we already have the precedent where “hashes” is defined on both the Artifact and File Objects.

Anyhow, our thinking is that with these changes you can still capture TTP-related
metadata about encrypted files (e.g., those dropped by malware) using the
File Object but also retain the ability to provide additional artifact-specific
information via the Artifact Object (including decryption key). Similarly,
if you wish to characterize the contents of an archive file, you can achieve
this via the existing Archive File Extension.  
 
Let us know what you think – maybe there’s something we’re missing or
a better way to go about this.
 
Regards,
Ivan