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

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

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